CVE-2026-23918: The Apache HTTP/2 Double-Free That Could Take Down Your Server

If your infrastructure runs Apache HTTP Server with HTTP/2 enabled — and statistically, there’s a good chance it does — you need to pay attention. CVE-2026-23918, disclosed in early May 2026, is a critical double-free vulnerability in mod_http2 that enables both denial-of-service and, under specific conditions, remote code execution. With a CVSS score of 8.8, this isn’t one to sit on.

TL;DR

• CVE-2026-23918 is a double-free vulnerability in Apache HTTP Server 2.4.66’s mod_http2 module with a CVSS score of 8.8
• Exploitation is trivial for DoS — a single crafted HTTP/2 request can crash any default deployment using multi-threaded MPMs
• Remote code execution is possible under specific heap conditions, making this a critical patch priority
• Only Apache 2.4.66 with mod_http2 and multi-threaded MPMs (worker/event) is affected — prefork is safe
• The fix is in Apache 2.4.67 — patch immediately or disable mod_http2 as a temporary mitigation

What Happened: The Technical Breakdown

The vulnerability lives in the stream cleanup path of h2_mplx.c, the multiplexer component that manages HTTP/2 streams. The bug is elegantly simple — which makes it all the more dangerous.

Here’s the sequence that triggers it:

1. A client sends an HTTP/2 HEADERS frame to open a new stream
2. Immediately after, before the multiplexer has fully registered the stream, the client sends an RST_STREAM with a non-zero error code on the same stream
3. Two nghttp2 callbacks fire in rapid succession: on_frame_recv_cb for the RST and on_stream_close_cb for the close
4. Both callbacks call h2_mplx_c1_client_rst, which in turn calls m_stream_cleanup
5. The same h2_stream pointer gets pushed onto the spurge cleanup array twice
6. When c1_purge_streams iterates and calls h2_stream_destroy on each entry, the second call operates on already-freed memory

This is a textbook double-free. The first h2_stream_destroy frees the memory and returns it to the allocator. The second call then operates on a dangling pointer — memory that may have already been reallocated for something else entirely.

Why This Is Worse Than a Typical DoS

Denial-of-service via this vulnerability is trivial. A single malformed HTTP/2 request can crash the server process. No authentication required. No complex exploitation chain. Just a HEADERS frame followed by a well-timed RST_STREAM.

But it doesn’t stop there. Double-free vulnerabilities are a well-understood class of memory corruption bugs. When heap memory is freed twice, an attacker who can control the contents of the reallocated memory between the first and second free can potentially:

• Corrupt heap metadata to gain arbitrary write primitives
• Overwrite function pointers to redirect execution
• Chain with other primitives to achieve full remote code execution

While RCE exploitation is more complex and depends on heap layout and allocator behaviour, the fact that it’s theoretically possible elevates this from “annoying crash” to “critical infrastructure risk.”

Who’s Affected

The vulnerability specifically affects:

• Apache HTTP Server version 2.4.66 (and only this version)
• mod_http2 must be enabled (it is by default on many distributions)
• A multi-threaded MPM must be in use — worker, event, or similar

Crucially, if you’re running MPM prefork (single-threaded, one process per connection), you’re not affected. The race condition that causes the double-free requires concurrent thread execution in the multiplexer.

However, most modern Apache deployments use MPM event or MPM worker for performance reasons. If you deployed or updated Apache any time in late 2025 or early 2026, there’s a reasonable chance you’re running 2.4.66.

The Fix: Patch or Mitigate

Option 1: Upgrade to Apache 2.4.67 (Recommended)

The Apache team has released version 2.4.67, which adds a registration check in the stream cleanup path to prevent the same stream pointer from being pushed onto the purge array more than once. This is the cleanest fix.

# Debian/Ubuntu
sudo apt update && sudo apt upgrade apache2

# RHEL/CentOS/Rocky
sudo dnf update httpd

# Verify version
apachectl -v

Option 2: Disable mod_http2 (Temporary Mitigation)

If you cannot patch immediately, disabling HTTP/2 eliminates the attack surface:

# Debian/Ubuntu
sudo a2dismod http2
sudo systemctl restart apache2

# RHEL/CentOS
# Comment out LoadModule http2_module in httpd.conf
sudo systemctl restart httpd

This trades HTTP/2 performance benefits for security — an acceptable trade-off until you can schedule the upgrade.

Option 3: WAF Rules

Some WAF providers have already pushed rules to detect the HEADERS+RST_STREAM pattern. However, this is a network-level protocol attack, not a payload-based one — WAF coverage may be incomplete. Don’t rely on this as your sole mitigation.

Lessons for Development Teams

This vulnerability reinforces several principles that every team managing web infrastructure should internalise:

1. Know your server configuration. Many teams deploy Apache without fully understanding which modules are loaded. If you don’t need HTTP/2, don’t enable it. If you do need it, ensure you have a rapid patching process.

2. Protocol-level bugs are the hardest to catch. This wasn’t a misconfiguration or a logic flaw in application code. It was a race condition in the HTTP/2 implementation itself. Your application-layer security tools won’t detect this.

3. The patch window is shrinking. With 28.3% of CVEs now exploited within 24 hours of disclosure, the old “patch Tuesday” cadence is inadequate. You need automated vulnerability scanning and rapid deployment pipelines.

4. Defence in depth matters. If your only protection is “Apache is up to date,” a single missed patch puts you at risk. Layer your defences: reverse proxies, network segmentation, runtime protection, and monitoring for anomalous HTTP/2 behaviour.

What We’d Recommend

At REPTILEHAUS, we help teams build infrastructure that doesn’t crumble when the next critical CVE drops. That means:

• Automated patch pipelines that can deploy security fixes within hours, not weeks
• Infrastructure as Code so you know exactly what’s running and can audit module configurations across your fleet
• Continuous vulnerability scanning integrated into your CI/CD pipeline
• Incident response playbooks so your team knows exactly what to do when a CVSS 8.8 drops on a Friday afternoon

If your team is still manually managing Apache configurations or patching servers by hand, it’s time to modernise. Get in touch — we specialise in building resilient, secure infrastructure that keeps your applications running even when the next zero-day lands.

Timeline

• Discovery: Bartlomiej Dmitruk (Striga.ai) and Stanislaw Strzalkowski (ISEC.pl)
• Affected version: Apache HTTP Server 2.4.66
• Fixed in: Apache HTTP Server 2.4.67
• CVSS: 8.8 (High)
• Vector: Network / No authentication required

📷 Photo by David Pupăză (@davidpupaza) on Unsplash