CVE-2026-23918: Apache HTTP/2 Double-Free Vulnerability with Possible RCE
A high-severity double-free vulnerability in Apache HTTP Server 2.4.66 allows low-privileged attackers to remotely crash vulnerable servers through a crafted HTTP/2 request sequence, with a demonstrated path to remote code execution on common Linux deployments.
Tracked as CVE-2026-23918, the vulnerability exists in Apache’s mod_http2 module and affects deployments using multi-threaded MPMs such as worker and event. The exploit requires only a crafted sequence of HTTP/2 frames sent over a single TCP connection. Because HTTP/2 is widely enabled across modern web infrastructure, both internet-facing and internally exposed Apache deployments may be at risk.
What Is CVE-2026-23918?
CVE-2026-23918 is a double-free vulnerability (CWE-415) in Apache HTTP Server’s HTTP/2 implementation. The vulnerability was introduced in Apache HTTP Server 2.4.66 following allocator-related changes inside mod_http2 v2.0.33. Under specific timing conditions, HTTP/2 stream cleanup logic can release the same memory region twice, leading to worker instability and memory corruption.
Reported by striga.ai and isec.pl. Researchers disclosed the vulnerability to Apache in December 2025. Apache addressed it in version 2.4.67.
Risk Profile
Risk Analysis
Severity: High
CVSS v3.1 Score : 8.8
Exploit Availability: Yes
Exploit Complexity: Low
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Root Cause of CVE-2026-23918
The vulnerability profile is CWE-415, a Double Free caused by unsafe memory handling inside Apache HTTP Server’s HTTP/2 implementation. The vulnerable logic exists within mod_http2, specifically in the h2_mplx.c stream management layer responsible for handling concurrent HTTP/2 requests. Apache uses internal h2_stream objects to track active streams throughout request processing and cleanup.
In Apache HTTP Server 2.4.66, allocator-related changes introduced in mod_http2 v2.0.33 altered how stream cleanup was coordinated during early stream termination scenarios. The exploitation sequence relies on a race condition between stream registration and cleanup operations.
Affected component: mod_http2 v2.0.33 (shipped with Apache 2.4.66). The double-free condition is rooted in unsynchronized ownership tracking across HTTP/2 cleanup callbacks.
How the Exploit Works
Step 01
Stream Creation via HEADERS Frame
The attacker creates a new HTTP/2 stream using a HEADERS frame. Apache allocates an internal h2_stream object and begins registering it within the HTTP/2 multiplexing layer. Before registration completes, the stream remains in a transitional state where multiple callbacks can still reference the same object.
Step 02
Early Stream Reset During Registration
Immediately after creating the stream, the attacker sends an RST_STREAM frame with a non-zero error code. This triggers cleanup handling before registration is complete. Under these timing conditions, separate HTTP/2 callbacks execute cleanup operations against the same h2_stream instance. Because ownership tracking is not properly synchronized, both callbacks treat the same memory region as eligible for release.
Step 03
Duplicate Cleanup and Heap Corruption
As Apache processes its cleanup queue, the same memory pointer is released twice. The first operation frees the memory successfully, while the second corrupts heap structures inside the worker process, leading to service instability and crashes. Researchers demonstrated that carefully controlled heap allocations under certain allocator conditions may create a potential path toward remote code execution.
Who Is Affected?
CVE-2026-23918 affects systems running Apache HTTP Server 2.4.66 with mod_http2 enabled under multi-threaded MPM configurations such as worker and event. Risk increases in environments where HTTP/2 is accessible to external or untrusted clients.
| Deployment Type | Affected? | Notes |
|---|---|---|
| Apache 2.4.66 — worker / event MPM | Yes | Primary attack surface. HTTP/2 must be enabled. |
| Apache 2.4.66 — prefork MPM | No | Not impacted by this vulnerability. |
| Apache with APR mmap allocator | Higher risk | Predictable allocation behavior can simplify memory manipulation. |
| Containerized / Docker deployments | Yes | Official Apache Docker images may carry affected allocator behavior by default. |
| Kubernetes / auto-scaling environments | Yes | Outdated base images can spread quickly across replicated workloads. |
| Apache 2.4.67 and later | No | Patched. Upgrade immediately. |
Container environments face broader exposure. In Kubernetes and auto-scaling setups, vulnerable images spread quickly across replicated workloads if outdated base images remain in deployment pipelines.
CVE-2026-23918 Mitigation & Remediation
Organizations running Apache HTTP Server 2.4.66 should upgrade to version 2.4.67 immediately. The update removes the vulnerable HTTP/2 code path and addresses additional security vulnerabilities fixed in the same release.
Upgrade to Apache 2.4.67
The patch removes the vulnerable HTTP/2 stream cleanup code path entirely. This is the only complete remediation. Ubuntu advisory USN-8239-1 covers this vulnerability for Ubuntu-based deployments.
Disable HTTP/2
Where immediate patching is not operationally feasible, disabling HTTP/2 reduces immediate exposure. Add Protocols http/1.1 to your Apache configuration. This does not remove the underlying vulnerability.
Rebuild Container Images
Rebuild container images with updated Apache base layers to prevent vulnerable workloads from being redeployed through CI/CD pipelines. Review infrastructure for vulnerable 2.4.66 deployments across all containerized and auto-scaling environments.
Monitor for Exploitation Signs
Unexpected worker crashes, repeated restart patterns, or unusual HTTP/2 connection behavior should be investigated promptly. These may indicate active exploitation attempts against CVE-2026-23918.
CVE-2026-23918: AppTrana Coverage
AppTrana customers are protected against CVE-2026-23918. Indusface’s expert team has deployed dedicated protection targeting the malicious HTTP/2 frame handling patterns associated with this vulnerability.
AppTrana rejects suspicious HTTP/2 traffic during request parsing itself. Because the exploit relies on crafted HEADERS and RST_STREAM frame sequences inside Apache mod_http2, malformed frames are blocked before they can reach vulnerable backend servers.