CVE-2026-119618: mod_http2 Race RCE

Apache shipped httpd 2.4.71 on November 11, fixing three CVEs including CVE-2026-119618 — a critical race condition in the mod_http2 module that leads to heap corruption and unauthenticated remote code execution on any server running HTTP/2 with default configuration. The bug was found independently by Anthropic’s OSS Scanner (ANT-2026-MAPKT6MZ) and Anthony Weems together with Simon Scannell of Google Cloud Vulnerability Research. Here is how the race works, how I reproduced it in a Docker lab using the stock official images, and how to fix it.

🔗 Apache HTTP Server 2.4 Security Advisory · Fix commit 824beab9b9 · NVD page · Researcher PoC repo

The Basics

CVE-2026-119618 is a concurrent execution using shared resource without synchronisation (CWE-362 / CWE-366) in Apache httpd’s mod_http2 module. The race hits assign_headers() in h2_request.c when a worker thread writes a synthesised Content-Length header into the mod_http2 shared stream pool — a data structure that the connection thread may be reading from simultaneously.

Technical Deep Dive

The vulnerable function assign_headers() in modules/http2/h2_request.c copies HTTP/2 HEADERS frame data into the request record that the worker thread processes. When the request body has ended — eos seen before headers arrive — the function needs to signal a zero-length body. It does this by writing Content-Length: 0 into what it thinks is the request’s header table.

The bug: it wrote this value into req->headers — a pointer to the mod_http2 shared stream pool — instead of into r->headers_in, the Apache request object’s own header table. Because req->headers points to connection-level memory, a worker thread’s write here races against the connection thread’s concurrent reads and writes on the apr_table_t allocator. Two threads hitting the pool’s free-list simultaneously produces either a use-after-free (heap read into freed memory) or a double-free (APR assert failure). Both can escalate to RCE.

The fix is a one-line change in commit 824beab9b9:

# --- h2_request.c (assign_headers) ---
# Vulnerable (2.4.55-2.4.70):
  apr_table_setn(req->headers, "Content-Length", "0");

# Fixed (2.4.71, commit 824beab9b9):
  apr_table_setn(r->headers_in, "Content-Length", "0");

# --- h2_request.c (assign_headers) ---
# Vulnerable (2.4.55-2.4.70):
  apr_table_setn(req->headers, "Content-Length", "0");

# Fixed (2.4.71, commit 824beab9b9):
  apr_table_setn(r->headers_in, "Content-Length", "0");

The fixed version writes into r->headers_in, which is the per-request table that only one worker thread ever touches. The shared stream pool is no longer mutated and the race disappears.

Lab Reproduction

I set up a differential lab using the official Docker images — httpd:2.4.70 (vulnerable) and httpd:2.4.71 (patched). No custom build, no ASan instrumentation — just stock binaries with h2c (cleartext HTTP/2) enabled. (The same Docker host I use for reclaiming disk space was fine for this.)

# Start vulnerable side (httpd 2.4.70)
docker run -d --name lab-vuln -p 127.0.0.1:18080:80 \
  -v $PWD/vconf/httpd.conf:/usr/local/apache2/conf/httpd.conf:ro \
  -v $PWD/vlogs:/logs httpd:2.4.70

# Start patched side (httpd 2.4.71)
docker run -d --name lab-fixed -p 127.0.0.1:18081:80 \
  -v $PWD/fconf/httpd.conf:/usr/local/apache2/conf/httpd.conf:ro \
  -v $PWD/flogs:/logs httpd:2.4.71

# Start vulnerable side (httpd 2.4.70)
docker run -d --name lab-vuln -p 127.0.0.1:18080:80 \
  -v $PWD/vconf/httpd.conf:/usr/local/apache2/conf/httpd.conf:ro \
  -v $PWD/vlogs:/logs httpd:2.4.70

# Start patched side (httpd 2.4.71)
docker run -d --name lab-fixed -p 127.0.0.1:18081:80 \
  -v $PWD/fconf/httpd.conf:/usr/local/apache2/conf/httpd.conf:ro \
  -v $PWD/flogs:/logs httpd:2.4.71

The key config line that makes the bug visible is the LogFormat directive: %{{Content-Length}}i records the request’s incoming Content-Length header exactly as the request handler sees it. The researcher’s deterministic functional probe sends a single HTTP/2 request and then greps the access log — no race needed.

Next I ran the race-inducing exploit mode against both sides — 24 simultaneous HTTP/2 connections, each driving 32 concurrent streams with 78 filler headers to maximise contention on the stream pool allocator. The vulnerable side suffered 2 worker crashes with SIGSEGV during the 60-second run. The patched side handled identical traffic with zero crashes.

I also verified the published workaround — removing h2/h2c from the Protocols directive. Against a 2.4.70 container with Protocols http/1.1 the PoC correctly reported “RESULT: MITIGATED — HTTP/2 is not offered, the CVE is unreachable”.

Detection

On a non-instrumented server the race leaves traces in the error log. With the LogFormat adjusted, the access log also reveals the bug without needing to trigger it:

# Find worker crashes linked to http2 traffic
grep -E "Segmentation fault|child pid.*exit signal" /var/log/apache2/error.log

# Probe without race — access log Content-Length signature
# Requires: LogFormat '... h2clen="%{Content-Length}i"' common
grep -c 'h2clen="-"' /var/log/apache2/access.log

# Find worker crashes linked to http2 traffic
grep -E "Segmentation fault|child pid.*exit signal" /var/log/apache2/error.log

# Probe without race — access log Content-Length signature
# Requires: LogFormat '... h2clen="%{Content-Length}i"' common
grep -c 'h2clen="-"' /var/log/apache2/access.log

Mitigation

The definitive fix is upgrading to Apache httpd 2.4.71 (released 11 November 2026) or applying the one-line patch from commit 824beab9b9. If you use mod_h2 as a standalone module from GitHub, update to version 2.0.43.

Workaround: remove h2 / h2c from the Protocols directive. This disables all HTTP/2 benefits, so treat it as a temporary control until the upgrade is deployed.

The assign_headers() race is one of those vulnerabilities that looks trivial in hindsight — a single pointer dereference separating a safe per-request table from a shared pool turns a harmless header write into a concurrent-use-after-free. If you run Apache servers with HTTP/2 enabled the upgrade to 2.4.71 is the safest option. If you run Apache behind DirectAdmin, the Custom Build tool should pick up 2.4.71 automatically. For readers who prefer to see PoCs running in a sandbox, the PHP2Shell article from last month follows a similar containerised reproduction pattern.