Apache HTTP/2 Double-Free Bug Enables DoS and RCE on Default Installs

A critical double-free memory corruption vulnerability in Apache HTTP Server's mod_http2 module can be exploited for denial of service on any default deployment—and remote code execution on Debian-derived systems. CVE-2026-23918 carries a CVSS score of 8.8 and affects Apache 2.4.66 running multi-threaded MPM configurations.

The attack requires only a single TCP connection and two HTTP/2 frames to trigger. No authentication needed.

How the Attack Works

The vulnerability lives in the stream cleanup path of h2_mplx.c within mod_http2. When a client sends an HTTP/2 HEADERS frame immediately followed by RST_STREAM with a non-zero error code on the same stream—before the multiplexer registers the stream—two nghttp2 callbacks fire sequentially.

Both callbacks invoke h2_mplx_c1_client_rst, which pushes the same pointer onto a cleanup array twice. When the cleanup routine later frees that memory, the second free operates on already-freed memory. Classic use-after-free territory.

Security researchers Bartlomiej Dmitruk of Striga.ai and Stanislaw Strzalkowski of ISEC.pl discovered and reported the flaw.

Exploitation Paths

Denial of Service is trivial on any default Apache deployment using mod_http2 with multi-threaded MPM (worker or event). An attacker opens one connection, sends the two-frame sequence, and crashes the server. Repeat as needed.

Remote Code Execution becomes achievable on systems where APR uses the mmap allocator—which includes Debian-derived Linux distributions and official Apache httpd Docker images. The exploitation chain involves placing a fake h2_stream struct at freed addresses and abusing Apache's scoreboard memory to gain control.

MPM prefork configurations are not affected since the race condition requires threads.

Scope and Exposure

mod_http2 ships in default Apache builds, and HTTP/2 is widely enabled in production environments. The attack surface is substantial. Any web server, reverse proxy, or load balancer running vulnerable Apache versions with HTTP/2 enabled is at risk.

This adds to a difficult year for Apache components. We've previously covered critical XXE vulnerabilities in Apache Tika and Apache Struts—different codebases, but a pattern of serious flaws in the Apache ecosystem.

Remediation

Upgrade to Apache 2.4.67 which contains the fix.

If immediate upgrade isn't possible:

1. Disable HTTP/2 by removing or commenting out Protocols h2 h2c directives
2. Switch to MPM prefork if HTTP/2 is required (performance tradeoff but eliminates the race)
3. Use a reverse proxy that terminates HTTP/2 before reaching vulnerable Apache instances

Organizations running Apache in Docker containers should pay particular attention—the official images use the vulnerable APR mmap allocator configuration, making RCE more likely.

Detection

Look for:

• Unexpected Apache crashes or restarts
• HTTP/2 connections with immediate RST_STREAM after HEADERS
• Anomalous memory patterns in core dumps

Given the low complexity of the DoS attack, any unexplained Apache instability on HTTP/2-enabled servers should prompt immediate investigation.

Why This Matters

Two frames, one connection, no auth—and you can either crash a server or potentially take it over. That's an exceptionally low barrier to exploitation for a vulnerability affecting one of the internet's most widely deployed web servers.

The RCE path being specific to certain allocator configurations provides some comfort, but the DoS path works everywhere mod_http2 runs with threading. For attackers who just want disruption, this is a gift.

Security teams managing web infrastructure should treat this as a priority patch. The technical details are public, exploitation is straightforward, and the fix is available. The window between now and when exploit scripts circulate widely is shrinking.