Critical RCE Vulnerability Patched in Apache HTTP Server
The **Apache Software Foundation (ASF)** has released security updates to address a critical remote code execution (RCE) vulnerability in the **Apache HTTP Server**. Tracked as **CVE-2026-23918**, the flaw stems from a double-free issue in the HTTP/2 protocol handling.

### Double-Free Vulnerability in HTTP/2
The vulnerability, identified as **CVE-2026-23918** (CVSS score: 8.8), is described as a "double free and possible RCE" in the HTTP/2 protocol handling. This affects **Apache HTTP Server** 2.4.66 and has been patched in version 2.4.67.
**Bartlomiej Dmitruk**, co-founder of Striga.ai, and **Stanislaw Strzalkowski**, a researcher at ISEC.pl, are credited with discovering and reporting the vulnerability.
### Technical Details and Exploitation
According to Dmitruk, the severity of **CVE-2026-23918** is critical, as it can be exploited for both denial-of-service (DoS) and RCE. He elaborated on the technical specifics:
> *CVE-2026-23918 is a double-free in Apache httpd 2.4.66 `mod_http2`, specifically in the stream cleanup path of h2_mplx.c. The bug triggers 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 has registered the stream.*
> *Two nghttp2 callbacks then fire in sequence, on_frame_recv_cb for the RST and on_stream_close_cb for the close, and both end up calling h2_mplx_c1_client_rst -> m_stream_cleanup, which pushes the same h2_stream pointer onto the spurge cleanup array twice. When c1_purge_streams later iterates spurge and calls h2_stream_destroy -> apr_pool_destroy on each entry, the second call hits memory that has already been freed.*
Dmitruk explained that the DoS attack is straightforward on any default deployment with `mod_http2` and a multi-threaded MPM (**Multi-Processing Module**). The RCE, however, requires an **Apache Portable Runtime (APR)** with the mmap allocator, which is the default on Debian-derived systems and the official httpd Docker image.
### RCE Exploit Path
Dmitruk further detailed the RCE exploit:
> *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. Apache respawns it, but every request on the crashed worker is dropped, and the pattern can be sustained as long as the attacker keeps sending.*
> *The second outcome is remote code execution, and we built a working proof of concept on x86_64. The chain places a fake h2_stream struct at the freed virtual address via mmap reuse, points its pool cleanup function to `system()`, and uses Apache's scoreboard memory as a stable container for the fake structures and the command string.*
> *The scoreboard sits at a fixed address for the lifetime of the server, even with ASLR, which is what makes the RCE path practical. The usual caveats apply: practical exploitation requires an info leak for `system()` and the scoreboard offsets, and the heap spray is probabilistic, but in lab conditions execution lands in minutes.*
### Mitigation and Recommendations
Dmitruk clarified that the MPM prefork is not affected by the flaw. However, he cautioned that the attack surface is significant, as `mod_http2` is included in default builds and HTTP/2 is widely enabled in production environments. Users are strongly advised to apply the latest fixes to mitigate the risk posed by this vulnerability.