If you’re running Apache HTTP Server 2.4.66, stop reading and patch. There’s a critical-rated HTTP/2 flaw (CVE-2026-23918) that lets an unauthenticated attacker crash your web server with two frames over a single TCP connection. And on common Linux setups, the same bug can be escalated to remote code execution.
The good news: only one Apache version is affected, and the fix is a one-version upgrade to 2.4.67. The bad news: that one version is widely deployed, and the DoS half of the attack is trivially weaponizable.
What is CVE-2026-23918?
It’s a double-free memory error inside mod_http2, the module that gives Apache its HTTP/2 support. CVSS score is 8.8 — high enough that vendor advisories are using the word “critical.”
The flaw was disclosed by Bartlomiej Dmitruk (Striga.ai) and Stanislaw Strzalkowski (ISEC.pl). Apache shipped the patch in version 2.4.67. Active exploitation in the wild had not been confirmed at the time of disclosure, but the proof-of-concept work makes that a “when,” not “if.”
How the attack works in plain English
HTTP/2 lets clients open many streams over one connection. Each stream goes through a quick registration step on the server before it’s fully tracked.
The bug shows up when a client sends an HTTP/2 HEADERS frame and immediately follows it with a RST_STREAM frame containing a non-zero error code before the server has finished registering the stream. Two internal callbacks then run one after another, both calling the same cleanup function on the same stream pointer.
End result: the same pointer ends up in Apache’s cleanup queue twice. When the server frees it the second time, you’ve got a classic double-free. From there you can either crash the worker (denial of service) or do something much worse.
According to The Hacker News, the DoS path needs “one TCP connection, two frames, no authentication, no special headers, no specific URL.” That’s about as low-friction as a server-side attack gets.
Who is at risk?
You’re affected if all three of these are true:
- You’re running Apache HTTP Server 2.4.66 specifically. Versions 2.4.65 and earlier don’t have this code path. 2.4.67 and later have the fix.
- You have
mod_http2loaded (which is the default in most distributions and Docker images). - You’re using a multi-threaded MPM — usually
workerorevent. The olderpreforkMPM is unaffected.
Two specific deployments need extra attention:
- Debian-derived Linux systems (Debian, Ubuntu, and downstream). These ship the Apache Portable Runtime with the mmap allocator by default, which is exactly what the RCE proof-of-concept depends on.
- Official Apache Docker images. Same default. If your container is on
httpd:2.4.66, you’re holding the vulnerable version.
Per SOCRadar’s analysis, this combination is “wide production deployment” — meaning a meaningful slice of the public-facing Apache servers on the internet right now.
Two attack paths: DoS vs RCE
The vulnerability has two operational tiers, and they require very different attacker skill levels.
1. Denial of service (trivial)
Send the two-frame sequence and the Apache worker crashes. Apache will respawn the worker, but you can hammer it in a loop and keep the server unable to handle legitimate traffic. No authentication, no special tooling. Anyone who can open a TCP connection can do this.
2. Remote code execution (complex but proven)
The researchers built a working proof-of-concept on x86_64. The technique places a fake h2_stream struct at the freed virtual address by abusing mmap allocation reuse, then points the pool’s cleanup function to system(). When Apache tries to clean up the “stream,” it executes whatever command the attacker chose.
That’s not trivial — you need accurate heap-layout knowledge and timing. But the fact that researchers shipped a working PoC means it’s reproducible, and any well-resourced attacker can replicate the path.
Security Affairs notes the RCE path is specifically viable on the mmap allocator setup mentioned above.
How to fix it
You have three options, in order of preference:
- Upgrade to Apache HTTP Server 2.4.67. This is the only real fix. Most Linux distributions have backported patches by now — check your package manager.
- Disable HTTP/2. If you can’t upgrade today, comment out the
LoadModule http2_moduleline in your Apache config and restart. You’ll lose HTTP/2 (and the performance benefits), but the attack surface goes away. - Switch to MPM prefork. If your workload allows it, switching from the worker or event MPM to prefork makes the server unaffected. This usually hurts performance for high-concurrency workloads, so treat it as a last resort.
For Docker users: bump your base image. httpd:2.4.67 or later is what you want.
Why a “single version” CVE matters more than it sounds
It’s tempting to look at “only 2.4.66 affected” and assume the impact is small. It isn’t.
Apache 2.4.66 was current for several months. Anyone who patched promptly during that window is now sitting on the vulnerable version. The people who didn’t patch — and there are many — are now running an even older version with its own problems.
This is the awkward middle ground in CVE response: the responsible patchers got rewarded with the next vulnerability, and the slow patchers are still safe from this one because they never moved.
The fix is the same either way: get to 2.4.67 immediately and set up alerting for the next Apache security advisory.
Frequently asked questions
Is CVE-2026-23918 being actively exploited?
At the time of disclosure, exploitation in the wild had not been confirmed. The DoS path is trivial, so opportunistic exploitation is likely already happening on a quiet scale. RCE attempts require more skill and are harder to detect.
Which Apache versions are affected?
Only Apache HTTP Server 2.4.66. Versions 2.4.65 and earlier are not affected because the vulnerable code path doesn’t exist. Version 2.4.67 and later contain the fix.
Do I need to update if I’m using nginx?
No. CVE-2026-23918 is specific to Apache’s mod_http2 module. nginx is unaffected. If you’re on Caddy, LiteSpeed, or any non-Apache web server, this CVE doesn’t apply to you.
What if I can’t patch immediately?
Disable mod_http2 by commenting out LoadModule http2_module in your Apache config and restarting Apache. You lose HTTP/2 support, but the vulnerability cannot be triggered without that module loaded.
Is my Docker container affected?
If your container uses the official httpd:2.4.66 base image, yes. Update to httpd:2.4.67 or later. The official Apache Docker image ships with the mmap allocator by default, which is the exact configuration the RCE proof-of-concept targets.
Will WAFs catch the attack?
The attack is just a normal HTTP/2 HEADERS frame followed by RST_STREAM — both legitimate protocol elements. Generic WAFs are unlikely to flag this without a specific signature for the malicious sequence. Don’t rely on a WAF as your primary defense; patch the server.
Bottom line
This is a “patch tonight if you’re running 2.4.66” situation, not a “schedule a maintenance window” situation. The DoS half of the vulnerability requires no skill to exploit, and the RCE half has a working proof-of-concept on a default Linux configuration.
Run httpd -v on your servers. If it says Apache/2.4.66, you have work to do.
Sources
- The Hacker News: Critical Apache HTTP/2 Flaw (CVE-2026-23918) Enables DoS and Potential RCE
- Security Affairs: Apache fixes critical HTTP/2 double-free flaw CVE-2026-23918 enabling RCE
- SOCRadar: Apache HTTP Server HTTP/2 Double Free With Possible RCE
- Hadrian: CVE-2026-23918 Apache HTTP Server Double-Free RCE Explained
- SentinelOne Vulnerability Database: CVE-2026-23918
- SecurityOnline: Millions at Risk — Apache HTTP Server Fixes Critical RCE
Last updated: May 23, 2026.