Apache Releases 2.4.67 to Patch Critical HTTP/2 Double-Free Vulnerability

On May 4, 2026, the Apache Software Foundation released HTTP Server version 2.4.67 to resolve CVE-2026-23918, a critical double-free vulnerability within the HTTP/2 handler. Assigned a CVSS score of 8.8, the flaw allows for Denial-of-Service (DoS) attacks with an exceptionally low barrier to entry—requiring only a single TCP connection and two malformed frames. Furthermore, the vulnerability introduces a path for Remote Code Execution (RCE) on platforms utilizing the APR mmap allocator, such as Debian distributions and official Docker images.

For infrastructure teams currently running version 2.4.66 with HTTP/2 enabled, this update represents an immediate operational priority that should not be deferred.

"The first is denial of service, which is trivial: one TCP connection, two frames, no authentication, no special headers, no specific URL, and the worker crashes." — Bartlomiej Dmitruk, co-founder of Striga.ai, via The Hacker News

The double-free mechanism: How two HTTP/2 frames corrupt memory

The vulnerability originates in the stream cleanup logic of h2_mplx.c, a core component of Apache’s HTTP/2 implementation. When a client transmits a HEADERS frame immediately followed by an RST_STREAM with a non-zero error code, the server executes two distinct calls that insert the identical h2_stream pointer into the purge cleanup array. Under normal operations, this array should contain only unique references. Here, the duplicate entry goes unnoticed because both code paths—request handling and reset reception—simultaneously flag the stream for disposal.

During the pool destruction phase, the initial apr_pool_destroy call frees the memory allocated to the stream. A subsequent call then attempts to operate on that same, already-released memory address, triggering the double-free condition. This heap memory corruption is sufficient to crash the worker process, leading to a temporary denial of service for that child process. In servers utilizing pre-fork or worker models, iterative crashes across multiple processes can progressively degrade the host's overall responsiveness.

From trivial DoS to RCE: Why the Apache scoreboard bypasses ASLR

The same memory corruption responsible for the crash can, under specific conditions, be weaponized for code execution. Researchers Bartlomiej Dmitruk and Stanislaw Strzalkowski developed a working proof-of-concept for the x86_64 architecture in a controlled environment, utilizing the mmap-based APR allocator. Because this allocator is the default setting for Debian and official Docker containers, the attack surface extends significantly beyond custom installations.

The core of the exploitation technique involves the Apache scoreboard—a data structure that tracks worker status and remains at a fixed address throughout the server process's lifecycle. Even with system-level Address Space Layout Randomization (ASLR) enabled, the scoreboard is not randomized, providing attackers with a stable memory anchor. Dmitruk noted that "the scoreboard sits at a fixed address for the lifetime of the server, even with ASLR, which is what makes the RCE path practical."

According to the researchers' analysis, the synergy between an mmap allocator and a predictable memory address made the laboratory RCE feasible. However, it has not been confirmed whether this exploit chain is viable outside of controlled environments or if the scoreboard is being used as an active container for the payload.

For teams managing Debian-based or Docker-hosted assets, the presence of the default mmap allocator necessitates treating these systems with maximum priority until the patch is applied.

Disclosure timeline: From December 2025 to the May 4 release

The vulnerability was discovered and reported to the Apache Security Team on December 10, 2025, by Bartlomiej Dmitruk (co-founder of Striga.ai) and Stanislaw Strzalkowski (ISEC.pl). The following day, December 11, 2025, the fix was committed to the repository (revision r1930444); however, coordinated disclosure was held under embargo until May 4, 2026.

This four-month window between the private commit and the public release meant that 2.4.66 installations remained exposed during the interval without an official bulletin available to administrators. There is currently no documented evidence of active exploitation during this period.

The 2.4.67 release addresses five vulnerabilities in total. In addition to CVE-2026-23918, it includes the moderate-severity CVE-2026-24072 and three minor flaws. Despite the multiple fixes, operational urgency remains centered on the double-free vulnerability.

Mitigation and Response

1. Immediate Update: Upgrade to Apache HTTP Server 2.4.67 if you are currently running version 2.4.66 with HTTP/2 enabled. The patch successfully eliminates the double-free condition in the h2_mplx.c cleanup path.
2. Allocator Verification: Audit the APR allocator in use on Linux systems. If the platform utilizes the default mmap allocator—standard on Debian and official Docker containers—the RCE risk demonstrated in laboratory settings is a direct threat. These assets should be prioritized for patching or isolated if an update is not immediately possible.
3. Emergency Workaround: If an immediate update is blocked by maintenance constraints or internal dependencies, consider temporarily disabling the HTTP/2 protocol. The vulnerability is strictly tied to the processing of malformed HTTP/2 frames; disabling the protocol closes the attack vector entirely.
4. Log Monitoring: Monitor web server logs for anomalous patterns, specifically single connections sending a HEADERS frame immediately followed by an RST_STREAM with a non-zero error code. Configuring alerts for this sequence can significantly reduce detection time for probing or DoS attempts.

The true danger of CVE-2026-23918 lies not in sophisticated APT-level complexity, but in the friction between its embarrassing simplicity and the widespread adoption of HTTP/2. When a web server can be destabilized with less traffic than a legitimate request, the line between a critical vulnerability and system instability disappears. For infrastructure teams, the primary defensive margin is the time taken to apply the 2.4.67 patch.

Frequently Asked Questions

Are versions prior to 2.4.66 vulnerable?

Current documentation identifies 2.4.66 as the only version affected by CVE-2026-23918. However, there is no technical guarantee that the bug is absent from earlier releases containing the vulnerable h2_mplx.c code. Updating remains the recommended best practice for all legacy installations.

Is RCE practical outside of a laboratory environment?

This remains unconfirmed. The working proof-of-concept was demonstrated under specific conditions on x86_64 systems using the APR mmap allocator (typical of Debian and Docker). There is currently no evidence of in-the-wild exploitation or successful replication on platforms using different allocators.

Why was the patch released in May 2026 if it was ready in December 2025?

Coordinated disclosure often involves an embargo to allow maintainers to prepare comprehensive releases. While the internal commit occurred on December 11, 2025, the public announcement was synchronized with the official 2.4.67 release. This is standard practice in open-source security, though it does leave installations exposed during the disclosure gap.

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

Sources

• https://thehackernews.com/2026/05/critical-apache-http2-flaw-cve-2026.html
• https://cybersecuritynews.com/apache-http-server-rce/