GHSA-G4F2-2PF3-2PWJ

Vulnerability from github – Published: 2026-10-15 20:09 – Updated: 2026-10-15 20:09
VLAI
Summary
react/http: Unbounded HTTP Client Response Header Buffering Leads to Memory Exhaustion DoS
Details

Summary

React\Http\Browser and its lower-level HTTP stack impose no limit on the size of a response's header section while it is being received. ClientRequestStream::handleData() appends every incoming byte to an internal buffer and only scans that buffer for the \r\n\r\n (or \n\n) terminator, without ever checking its length. A remote server that withholds the terminator and keeps streaming can grow the client's memory without bound until PHP's memory_limit is exhausted and the process crashes.

This is an unauthenticated, network-reachable denial of service against any application that uses react/http as a client to fetch untrusted or attacker-influenced URLs, including via redirects.

Details

ClientRequestStream::handleData() is bound directly to the underlying connection's data event, so every byte the peer sends is appended with no size check:

public function handleData($data)
{
    $this->buffer .= $data;

    // buffer until double CRLF (or double LF for compatibility with legacy servers)
    $eom = \strpos($this->buffer, "\r\n\r\n");
    $eomLegacy = \strpos($this->buffer, "\n\n");
    if ($eom !== false || $eomLegacy !== false) {

The only exit from the buffering state is finding the header terminator or a connection close, so until it arrives the buffer grows monotonically for as long as the peer keeps sending.

The codebase already applies this class of limit elsewhere, but not symmetrically. RequestHeaderParser caps incoming request headers when acting as a server, and Transaction::bufferResponse() caps the response body, but only once the header section has already been parsed into a Response. Response header reception was the one stage with no limit at all.

PoC

An HTTP server that sends a valid status line and a partial header, then streams indefinitely without ever terminating the header section:

php -r '$s=stream_socket_server("tcp://127.0.0.1:18080"); $c=stream_socket_accept($s); fread($c,8192); fwrite($c,"HTTP/1.1 200 OK\r\nX-Fill: "); while (true) { fwrite($c, str_repeat("A",1048576)); usleep(10000); }'

A client fetching it, with memory_limit=64M:

$browser = new React\Http\Browser();
$browser->get("http://127.0.0.1:18080/")->then(
    function () { echo "ok\n"; },
    function ($e) { echo get_class($e) . ": " . $e->getMessage() . "\n"; }
);

Client memory grows steadily until the process dies with Allowed memory size ... exhausted inside ClientRequestStream::handleData().

Impact

Remotely triggerable, unauthenticated denial of service against any process using Browser to fetch from an attacker-controlled, compromised or otherwise untrusted endpoint, including one reached through a redirect. No user interaction and no special privileges are required. Because there is no upper bound on the header buffer, a single cheap connection can drive memory arbitrarily high and crash the process, taking down whatever event loop or worker it was running. Confidentiality and integrity are unaffected; availability is fully impacted for that process.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.11.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "react/http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-104827"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-15T20:09:56Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`React\\Http\\Browser` and its lower-level HTTP stack impose no limit on the size of a response\u0027s header section while it is being received. `ClientRequestStream::handleData()` appends every incoming byte to an internal buffer and only scans that buffer for the `\\r\\n\\r\\n` (or `\\n\\n`) terminator, without ever checking its length. A remote server that withholds the terminator and keeps streaming can grow the client\u0027s memory without bound until PHP\u0027s `memory_limit` is exhausted and the process crashes.\n\nThis is an unauthenticated, network-reachable denial of service against any application that uses `react/http` as a client to fetch untrusted or attacker-influenced URLs, including via redirects.\n\n### Details\n\n`ClientRequestStream::handleData()` is bound directly to the underlying connection\u0027s `data` event, so every byte the peer sends is appended with no size check:\n\n```php\npublic function handleData($data)\n{\n    $this-\u003ebuffer .= $data;\n\n    // buffer until double CRLF (or double LF for compatibility with legacy servers)\n    $eom = \\strpos($this-\u003ebuffer, \"\\r\\n\\r\\n\");\n    $eomLegacy = \\strpos($this-\u003ebuffer, \"\\n\\n\");\n    if ($eom !== false || $eomLegacy !== false) {\n```\n\nThe only exit from the buffering state is finding the header terminator or a connection close, so until it arrives the buffer grows monotonically for as long as the peer keeps sending.\n\nThe codebase already applies this class of limit elsewhere, but not symmetrically. `RequestHeaderParser` caps incoming **request** headers when acting as a server, and `Transaction::bufferResponse()` caps the response **body**, but only once the header section has already been parsed into a `Response`. Response header reception was the one stage with no limit at all.\n\n### PoC\n\nAn HTTP server that sends a valid status line and a partial header, then streams indefinitely without ever terminating the header section:\n\n```bash\nphp -r \u0027$s=stream_socket_server(\"tcp://127.0.0.1:18080\"); $c=stream_socket_accept($s); fread($c,8192); fwrite($c,\"HTTP/1.1 200 OK\\r\\nX-Fill: \"); while (true) { fwrite($c, str_repeat(\"A\",1048576)); usleep(10000); }\u0027\n```\n\nA client fetching it, with `memory_limit=64M`:\n\n```php\n$browser = new React\\Http\\Browser();\n$browser-\u003eget(\"http://127.0.0.1:18080/\")-\u003ethen(\n    function () { echo \"ok\\n\"; },\n    function ($e) { echo get_class($e) . \": \" . $e-\u003egetMessage() . \"\\n\"; }\n);\n```\n\nClient memory grows steadily until the process dies with `Allowed memory size ... exhausted` inside `ClientRequestStream::handleData()`.\n\n### Impact\n\nRemotely triggerable, unauthenticated denial of service against any process using `Browser` to fetch from an attacker-controlled, compromised or otherwise untrusted endpoint, including one reached through a redirect. No user interaction and no special privileges are required. Because there is no upper bound on the header buffer, a single cheap connection can drive memory arbitrarily high and crash the process, taking down whatever event loop or worker it was running. Confidentiality and integrity are unaffected; availability is fully impacted for that process.",
  "id": "GHSA-g4f2-2pf3-2pwj",
  "modified": "2026-10-15T20:09:56Z",
  "published": "2026-10-15T20:09:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/reactphp/http/security/advisories/GHSA-g4f2-2pf3-2pwj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/reactphp/http/commit/2558622d0b76227c60c61eac8a61572cb6638e8c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/reactphp/http"
    },
    {
      "type": "WEB",
      "url": "https://github.com/reactphp/http/releases/tag/v1.11.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "react/http: Unbounded HTTP Client Response Header Buffering Leads to Memory Exhaustion DoS"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
Events included in the timeline

Loading timeline…


    Loading…

    Loading…

    Loading…

    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.