react/http: A malformed HTTP chunked body can lead to a denial-of-service and peg the CPU

A malformed HTTP message with Transfer-Encoding: chunked can make react/http loop indefinitely, use a full CPU core and stop the entire process responding until it is killed. This affects both React\Http\HttpServer receiving requests from malicious clients and React\Http\Browser receiving responses from malicious or compromised servers.

Check composer.lock for react/http versions from 0.6.0 to 1.11.0, inclusive; 1.11.1 is fixed. Check whether your application uses React\Http\HttpServer to receive chunked request bodies or React\Http\Browser to receive chunked response bodies. For server use, check whether a reverse proxy parses and re-frames HTTP before it reaches PHP. For client use, check whether outbound requests fetch attacker-influenced URLs; a reverse proxy in front of your application does not protect those requests.

On the server side, use a reverse proxy that parses and re-frames HTTP, such as a typical nginx setup, so requests are normalised before reaching PHP. This mitigation does not protect outbound requests made with Browser.

Summary

A malformed HTTP message using Transfer-Encoding: chunked can drive React\Http\Io\ChunkedDecoder into an infinite loop, pegging a CPU core and freezing the event loop. Because ReactPHP is single-threaded, one such message stalls the entire process for every client until it is killed.

Both directions are affected. ChunkedDecoder decodes chunked request bodies for React\Http\HttpServer and chunked response bodies for React\Http\Browser, so a server can be attacked by a malicious client and a client can be attacked by a malicious or compromised server.

Details

ChunkedDecoder::handleData() loops while ($this->buffer !== '') and relies on the buffer shrinking each iteration. Two states leave the buffer unchanged while the loop condition stays true.

Terminal-chunk trailer. After the terminating 0 chunk, any remaining buffer is treated as trailer data to skip:

} elseif ($this->chunkSize === 0) {
    $this->buffer = (string)\substr($this->buffer, $positionCrlf);
}

When the trailer holds no CRLF yet, strpos() returns false, PHP coerces that to 0 in substr(), and the buffer is never advanced. Neither the error guard (which requires a non-zero chunk size) nor the wait guard (which requires fewer than two bytes remaining) can fire, so the loop re-enters with identical state.

Off-by-one after a completed chunk. Once a non-terminal chunk has been fully transferred, the "chunk does not end with a CRLF" error guard requires strlen($this->buffer) > 2 while the wait guard requires < 2. Exactly two non-CRLF bytes slip past both, and because the chunk is already complete nothing is consumed on the next iteration.

PoC

Run the example server from the reactphp/reactphp README and send a malformed request. Note the missing trailing \r\n:

POST / HTTP/1.1\r\nHost: x\r\nTransfer-Encoding: chunked\r\n\r\n0\r\nab

The PHP process pegs at 100% CPU and stops answering legitimate requests. A body of 1\r\nAAB triggers the second state.

The client side is reachable the same way: a Browser request to a server that answers with Transfer-Encoding: chunked and either malformed body shape hangs the client process.

Impact

Denial of service. The affected process stops responding entirely and has to be killed.

Servers behind a reverse proxy that parses and re-frames HTTP, such as a typical nginx setup, are not affected on the server side, because the proxy normalises the request before it reaches PHP. That mitigation does not extend to the client side: outbound requests made with Browser reach the remote server directly, so an application fetching attacker-influenced URLs is affected regardless of what sits in front of it.