If you’re running web applications in PHP, especially using its built-in stream wrappers for HTTP requests, read on. A fresh security issue known as CVE-2024-11234 puts your server at risk of being exploited for HTTP request smuggling—specifically when configured with HTTP proxies and certain options. This post gives a straightforward breakdown of what went wrong, how an attacker could abuse it, and the steps you should take to protect your server and data.

What is CVE-2024-11234?

CVE-2024-11234 is a vulnerability found in the PHP stream wrappers used for making HTTP requests.

PHP 8.3.\* before 8.3.14

The problem happens when you make HTTP requests over a proxy with request_fulluri set to true. The PHP code does not sanitize the URI properly. This opens the door to HTTP request smuggling—an attack where malicious users sneak in extra requests or headers, confusing the receiving server or proxy, and letting attackers relay arbitrary HTTP requests from your server.

Let’s say your PHP code looks like this

<?php
$opts = array(
  'http'=>array(
    'proxy' => 'tcp://proxy.example.com:808',
    'request_fulluri' => true,
    'method' => 'GET'
  )
);

$context = stream_context_create($opts);
$file = file_get_contents('http://trusted.example.com/api/';, false, $context);
?>

With this configuration, PHP will send the full request URI to the proxy, including protocol and hostname.

The Problem: PHP doesn't properly sanitize the URI.
Result: If a user can control part of the URI (say, via user input), they may inject newline and control characters—smuggling entire new requests or altering headers.

`

http://trusted.example.com/api/%d%aGET%20/admin/secret%20HTTP/1.1%d%aHost:%20internal.app%d%a%d%a

`

GET http://trusted.example.com/api/
GET /admin/secret HTTP/1.1

Host: internal.app

HTTP/1.1

`

The proxy, receiving crafted raw requests, may forward both requests—one to the intended host, another to a private/internal resource, as though the server itself made the request.

Impact:

The attacker is able to trigger the PHP-hosting server to send HTTP requests on behalf of the attacker, accessing resources that are not otherwise externally available (for example, administrative endpoints or cloud metadata services).

Why Is This Dangerous?

- Server-Side Request Forgery (SSRF): Attackers may access internal resources, like metadata endpoints, databases, or admin panels.
- Bypassing Access Controls: The attack is performed by the server, so network-based protections may not work.
- Proxy Abuse: Proxies relaying the malicious request can cause hard-to-trace activity and open doors to lateral movement within networks.

Here’s a simplified PHP code for demonstration

<?php
$user_input = $_GET['uri'];  // Dangerous! Never trust user input for URIs.
$opts = [
  'http' => [
    'proxy' => 'tcp://proxy.local:808',
    'request_fulluri' => true,
    'method' => 'GET'
  ]
];
$context = stream_context_create($opts);
$result = file_get_contents($user_input, false, $context);
echo htmlentities($result);
?>

Malicious GET parameter

uri=http://victim/api/%d%aGET%20/internal/admin HTTP/1.1%d%aHost:%20internal.service%d%a%d%a

If not properly sanitized, this code makes the server send a second, hidden request via the proxy.

Official PHP Security Announcement:

https://www.php.net/ChangeLog-8.php#8.1.31

NVD Entry for CVE-2024-11234:

https://nvd.nist.gov/vuln/detail/CVE-2024-11234

PHPCS: Multiple Stream Context HTTP Injection

https://github.com/php/php-src/security/advisories/GHSA-xxx *(search for CVE-2024-11234 once made public)*

Never Trust User Input for URIs:

- Validate and sanitize all URIs before using them in file_get_contents(), fopen(), or cURL-like wrappers.

Conclusion

CVE-2024-11234 is a classic reminder that even trusted libraries and defaults can be dangerous in the right (or wrong) circumstances. If your PHP code makes external requests over HTTP proxies—especially when any part of the URI is influenced by outside input—patch now.

Stay secure, keep up on your updates, and always sanitize your inputs.


*This writeup is exclusively compiled for clarity and actionable advice. For deeper reading, check the references linked above.*

Timeline

Published on: 11/24/2024 01:15:03 UTC
Last modified on: 11/26/2024 19:06:10 UTC