CVE-2026-119618: Critical Apache HTTP/2 Flaw Puts Web Servers at Risk of Remote Code Execution
By SAFE Threat Research Team
Overview
On November 11, 2026, the Apache Software Foundation disclosed CVE-2026-119618, a critical memory-corruption vulnerability in the Apache HTTP Server’s mod_http2 module. Affecting versions 2.4.55 through 2.4.70, the flaw can allow unauthenticated remote attackers to trigger heap corruption, potentially leading to remote code execution (RCE).
The vulnerability stems from a race condition in HTTP/2 request processing, where concurrent threads access a shared memory allocator without proper synchronization. Unlike application-level vulnerabilities, this flaw is reachable within the web server itself, before application authentication or business logic is processed.
Apache released version 2.4.71 to address the issue. Public proof-of-concept (PoC) research is available, and we have independently reproduced the memory corruption against vulnerable builds. Organizations running affected HTTP/2-enabled infrastructure should prioritize remediation.
Vulnerability at a Glance
Why This Vulnerability Matters to Enterprises
Apache HTTP Server is widely used across public websites, reverse proxies, application gateways, and internal enterprise services. CVE-2026-119618 affects the underlying HTTP/2 processing layer, making it exploitable independently of the applications hosted behind the server.
An attacker only needs network access to a vulnerable HTTP/2 listener. No credentials or application-specific knowledge are required.
The immediate impact is memory corruption and potential disruption of Apache child processes. With additional exploitation techniques, the vulnerability could enable arbitrary code execution within the server process, potentially exposing application data, configuration files, and credentials accessible to that process.
The blast radius can extend beyond a single website. A vulnerable Apache instance serving multiple applications or virtual hosts may expose shared infrastructure to disruption or compromise.
However, exposure depends on the installed module, HTTP/2 configuration, and network reachability. Apache installations without the affected HTTP/2 functionality are not vulnerable through this attack path.
Technical Analysis: How CVE-2026-119618 Works
The Root Cause: A Shared Memory Allocation Race
Apache’s mod_http2 module supports concurrent request processing over HTTP/2 connections. To maintain thread safety, request-processing workers use separate memory allocation contexts managed by the Apache Portable Runtime (APR).
The vulnerability occurs in assign_headers(), which converts HTTP/2 headers into Apache’s internal request representation.
For certain requests without a body, Apache synthesizes a Content-Length: 0 header. In vulnerable versions, this value is written to the original HTTP/2 stream header table rather than to the request-private copy.
When the stream header table is full, adding this header requires additional memory. The operation can access the connection’s allocator, which is also used by another thread without adequate synchronization.
Concurrent allocation and deallocation can corrupt the allocator’s free list, potentially resulting in overlapping memory allocations, invalid memory accesses, and process crashes.
The publicly demonstrated trigger involves a body-less HTTP/2 request with a Content-Type header, no Content-Length, and a header table at capacity. The race manifests when the worker and connection threads access the affected allocator concurrently.
How Apache Fixed It
The patch changes a single statement in assign_headers().
Vulnerable implementation (2.4.70):
apr_table_setn(req->headers, "Content-Length", "0");
Patched implementation (2.4.71):
apr_table_setn(r->headers_in, "Content-Length", "0");
The original code modifies req->headers, associated with the HTTP/2 stream’s shared allocation context. The patch instead updates r->headers_in, which uses the worker’s request-private memory pool.
This change prevents the affected operation from accessing the unsafe shared allocator.
Exploitability: What Has Been Demonstrated?
We independently reproduced publicly available PoC research against Apache HTTP Server 2.4.70 and the patched 2.4.71 release.
Using AddressSanitizer (ASan) and ThreadSanitizer (TSan), we validated the memory corruption and underlying allocator race, then compared the results against the patched version and an HTTP/2-disabled configuration.
Exploit Validation Results
Figure 1: Our validation confirmed memory corruption in Apache HTTP Server 2.4.70, while the patched 2.4.71 build showed no corruption under equivalent test conditions.
Evidence of Memory Corruption
AddressSanitizer captured memory-safety failures in Apache’s HTTP/2 request-processing path, while ThreadSanitizer identified concurrent access to APR allocator structures. These findings support the root-cause analysis and demonstrate that the vulnerability can be reproduced under controlled conditions.
Figure 2: AddressSanitizer output captured during our internal validation, showing a memory-safety failure in the vulnerable Apache HTTP Server 2.4.70 build.
Our testing confirms remotely triggerable heap corruption and process instability, but does not establish a complete remote code execution chain. Nevertheless, the ability to corrupt server memory without authentication, combined with public PoC availability, makes this a high-priority vulnerability for exposed HTTP/2 infrastructure.
Attack Scenarios
Scenario 1 – Internet-facing httpd with HTTP/2 enabled
The most common case. A public web server terminates TLS with h2 enabled, or accepts cleartext h2c behind a load balancer that forwards HTTP/2 unchanged. An attacker opens a handful of connections, fills each with body-less requests carrying a Content-Type and a large header set, and keeps them cycling. No account, no session and no knowledge of the hosted application is required. The traffic can resemble ordinary HTTP/2 to a network sensor, because HPACK compresses repeated header names.
Scenario 1 – Attack flow
Attacker
|
| Open several h2c or h2 connections (preface, SETTINGS)
|
v
httpd mod_http2 (connection thread c1)
|
| POST, END_STREAM on HEADERS, Content-Type, no Content-Length
| 79 regular headers + Host = 80 of 80 table entries
|
v
Worker thread (c2) - assign_headers()
|
| apr_table_setn(req->headers, "Content-Length", "0")
| table full -> array grows -> 8 KB node requested
|
v
Connection allocator (no mutex) <-- c1 allocating/freeing at the same time | v Two threads own the same APR node -> heap corruption in child process
|
|--> Child crash or s_c2_done() assertion
|--> Repeated cycling keeps the window open -> corruption primitive
Scenario 2 – Internal or shared-hosting exposure
Internal reverse proxies, admin vhosts and shared-hosting front ends are often overlooked because they are not internet-facing. The exploit needs only reachability, and a compromised workstation or a single SSRF is enough. On shared platforms the corrupted child is shared infrastructure. Crashing it repeatedly degrades every tenant on the same process pool. Whether a successful chain would cross tenant boundaries is analysis and is not demonstrated by the PoC.
Scenario 2 – Attack flow (analysis, not demonstrated by the PoC)
Foothold (compromised workstation, SSRF, or a shared-hosting tenant)
|
| Reach an internal HTTP/2 listener (cleartext h2c is enough)
|
v
Internal reverse proxy or admin vhost (httpd 2.4.55 - 2.4.70)
|
| Same body-less, 79-header request as Scenario 1; no credentials
|
v
Shared child process corrupted
|
|--> Every tenant on the same process pool is degraded
+--> Optional: chain the primitive with a later step
Scenario 3 – Chained after any initial foothold
The trigger requires no privileges, so it is also a post-compromise local-network escalation. An attacker who can reach an internal HTTP/2-speaking service can turn a low-value foothold into a memory-corruption primitive on the web tier, independent of the application running above it. This escalation path is analysis and is not demonstrated by the PoC.
Scenario 3 – Attack flow (analysis, not demonstrated by the PoC)
Low-value foothold on any host in the internal network
|
| Reach a web tier that speaks HTTP/2
|
v
httpd mod_http2 (no authentication, no application context needed)
|
| Race on the connection allocator, as in Scenario 1
|
v
Memory-corruption primitive on the web tier
Detection and Mitigation: What Defenders Should Do Now
1. Identify Vulnerable Deployments
Inventory Apache installations across public-facing servers, internal gateways, containers, and vendor-managed infrastructure.
Confirm the Apache version, whether mod_http2 is active, and whether h2 or h2c is enabled.
httpd -v
httpd -M
Use the equivalent apache2 commands where applicable. Verify the effective protocol configuration, including proxy-to-origin connections.
2. Patch or Disable HTTP/2
Upgrade to Apache HTTP Server 2.4.71 or later, or install the equivalent vendor-supported security update.
Where immediate patching is not possible, temporarily disable HTTP/2 on affected listeners:
Protocols http/1.1
If HTTP/2 is required for clients, terminate it at a patched proxy and use HTTP/1.1 to the Apache origin. Ensure there are no alternate paths exposing the vulnerable HTTP/2 listener.
For archived standalone mod_h2 deployments, migrate to a maintained, patched implementation.
3. Monitor for Exploitation Attempts
Investigate the following indicators on potentially affected systems:
- Repeated Apache child-process crashes or unexpected worker restarts.
- Allocator-related errors, abnormal HTTP/2 failures, or core dumps.
- Unusual HTTP/2 request concurrency combined with large header sets.
- Unexpected processes spawned by Apache, particularly where accompanied by other compromise indicators.
These signals are not unique to CVE-2026-119618 and should be correlated with asset exposure and supporting telemetry.
HTTP/2-aware request limits and rate limiting may reduce suspicious traffic, but are not substitutes for patching.
4. Validate Remediation
Confirm that the updated deployments include the security fix and that the effective protocol negotiation matches the intended configuration.
Where HTTP/2 has been disabled, verify that affected listeners reject HTTP/2 connections, including those reachable through internal proxies or alternate network paths.
Conclusion
CVE-2026-119618 exposes a critical weakness in Apache’s HTTP/2 memory management. Our independent validation confirms that unauthenticated requests can trigger heap corruption in affected builds, while successful remote code execution remains a potential, rather than demonstrated, outcome.
With public PoC research available and a patch released, organizations should prioritize vulnerable HTTP/2 endpoints, deploy Apache 2.4.71 or vendor-equivalent fixes, and verify remediation across both internet-facing and internal infrastructure.
References
- Apache HTTP Server – Official Security Advisory
- Apache HTTP Server – Upstream Fix Commit
- Red Hat – CVE-2026-119618 Security Assessment
- Red Hat – Apache HTTP Server Security Bulletin
- NHS England – Apache HTTP Server Advisory
- Public PoC and Differential Lab Research