Critical Apache HTTP/2 Double-Free Flaw Enables RCE and Unauthenticated DoS

The Apache Software Foundation released Apache HTTP Server version 2.4.67 on May 4, 2026, to address CVE-2026-23918. This critical double-free vulnerability in the mod_http2 module allows unauthenticated remote attackers to crash worker processes using a single TCP connection. On systems utilizing the APR mmap allocator—the default configuration for Debian-derived distributions and official Docker images—the flaw facilitates a viable remote code execution (RCE) path, making the update an immediate priority for all internet-facing servers with HTTP/2 enabled.

The Double-Free Mechanism in h2_mplx.c

The vulnerability resides in the way the HTTP/2 multiplexer manages stream destruction within h2_mplx.c. When a client sends a HEADERS frame followed immediately by an RST_STREAM frame with a non-zero error code before the multiplexer formally registers the stream, two callbacks from the nghttp2 library are triggered: on_frame_recv_cb, which handles the reset, and on_stream_close_cb, which closes the stream.

Both callbacks invoke the h2_mplx_c1_client_rst function, which inserts the same h2_stream pointer into the internal spurge array. During the cleanup phase, the first call to h2_stream_destroy correctly releases the memory via apr_pool_destroy. However, the second call attempts to operate on the already released region, triggering the double-free condition. This stream lifecycle management error is the core of the flaw.

Trivial DoS: A Single TCP Connection is Enough

The most immediate impact is a remarkably simple remote denial-of-service attack. Attackers do not require authentication, special headers, or specific URLs: a single TCP connection and two frames—a HEADERS and an RST_STREAM—are sufficient to cause an abnormal termination of the Apache worker process.

In environments where mod_http2 is active, this means a single internet-exposed endpoint becomes a high-efficiency target for service disruption. The crash requires neither high traffic volume nor specific race conditions; a precise sequence of packets is all it takes. For services relying on the persistence of HTTP/2 connections, overall server stability is compromised by a zero-cost attack vector.

The RCE Path: mmap Reuse and Fixed Scoreboard

The second facet of the vulnerability is remote code execution, which is contingent on the use of an APR with the mmap allocator. This is the default configuration on Debian and the official httpd Docker image, broadening the attack surface significantly beyond custom server builds. Researchers have demonstrated that after the double-free, the vacated virtual address can be reassigned by placing a fake h2_stream struct within the mapped memory.

The pool cleanup function can then be hijacked to point toward system(). Meanwhile, the scoreboard memory—which remains at a fixed address for the entire lifetime of the server process, effectively bypassing ASLR—serves as a stable container for the fake structures and the command string. The combination of mmap reuse and a known memory address transforms a memory corruption bug into controlled execution, as demonstrated in laboratory settings.

"The second outcome is remote code execution, and we built a working proof of concept on x86_64. [...] The scoreboard sits at a fixed address for the lifetime of the server, even with ASLR, which is what makes the RCE path practical." — Bartlomiej Dmitruk (Striga.ai), via The Hacker News

Why Debian and Docker Amplify the Risk

Not all installations face the same level of danger. The MPM prefork architecture is explicitly immune, as its process-based design does not trigger the vulnerable code path. However, Debian-derived distributions and the official Apache container utilize the APR mmap allocator by default, exposing instances to the RCE path without any explicit configuration choices by the administrator.

For other platforms or custom configurations, it has not yet been verified if the same exploitation chain is equally effective. In the absence of independent confirmation, the minimum guaranteed risk remains a remote worker crash. The primary unknown is the practical reproducibility outside the lab, as the proof-of-concept is not public and has not been third-party tested. Nevertheless, where mmap is active, the exploitation theory remains solid.

Disclosure Timeline: Private Report to Public Release

The flaw was discovered by Bartlomiej Dmitruk, a researcher at Striga.ai, and Stanislaw Strzalkowski of ISEC.pl. The private report to the Apache security team was submitted on December 10, 2025; a corrective commit arrived the following day, identified as revision r1930444. Despite the fix being ready within twenty-four hours of the report, the public patch was only included in the 2.4.67 release on May 4, 2026.

This delay allowed nearly five months to pass between the internal resolution and official availability. During this period, internet-exposed version 2.4.66 instances remained without a public mitigation for a flaw already known to the vendor. The discrepancy between internal development speed and public release timing raises questions regarding the management of coordinated advisories for such high-stakes open-source projects.

Mitigation and Upgrade Paths

Upgrading to Apache httpd 2.4.67 is the primary and definitive countermeasure; the release fixes the double-free in the mod_http2 module without requiring additional configuration changes. If immediate patching is not feasible due to maintenance constraints, disabling mod_http2 entirely will eliminate the attack vector without affecting the server core.

Administrators should verify which MPM is currently in use: those running prefork can plan their rollout with a wider margin, while those utilizing worker or event with the APR mmap allocator must treat the intervention as critical. As a transitional mitigation, placing the server behind a reverse proxy or a Web Application Firewall (WAF) with HTTP/2 frame rate-limiting policies can reduce the probability of a targeted DoS, though it does not eliminate the structural risk associated with the memory allocator.

The severity of CVE-2026-23918 lies not only in the ease of the DoS but in the specific geometry of the RCE exploit: a reused memory allocation and a fixed scoreboard address turn a managed exception into a weapon aimed at some of the web's most common configurations.

This case also underscores challenges in vulnerability disclosure. A fix committed in a single day but released five months later leaves a significant window of exposure. For organizations, the takeaway is clear: enabling HTTP/2 on Apache without rapid updates leaves a door open that a single TCP packet can shut—or worse.

FAQ

Which configurations are at risk for RCE vs. DoS?

MPM prefork is not affected. The RCE path has been demonstrated on systems using the APR mmap allocator, which is the default for Debian and the official httpd Docker image. For other platforms, the confirmed minimum risk is a remote worker crash.

Why was the fix committed in December but released in May?

The Apache security team integrated the fix in revision r1930444 on December 11, 2025, but the public 2.4.67 release did not arrive until May 4, 2026. The exact reason for this delay has not been detailed by available sources.

Is the RCE exploit public and easily replicable?

No. The proof-of-concept was built by researchers in a controlled environment on the x86_64 architecture and has not been publicly released or independently verified. Practical reproducibility outside of lab conditions remains a known limitation.

Information verified via cited sources and accurate at the time of publication.

Sources

• https://thehackernews.com/2026/05/critical-apache-http2-flaw-cve-2026.html
• https://securityaffairs.com/191759/security/apache-fixes-critical-http-2-double-free-flaw-cve-2026-23918-enabling-rce.html
• https://www.vardaan-cyber.com/post/critical-apache-http-2-flaw-cve-2026-23918-enables-dos-and-potential-rce
• https://cybersecuritynews.com/apache-http-server-rce/