Apache HTTP/2 Bug Lets Attackers Hijack Every Site on a Server

Imagine a shared hosting box humming along on a Tuesday morning. Hundreds of WordPress sites are each isolated in their own PHP-CGI sandbox and separated from each other by a model that has defined multitenant hosting for nearly two decades. Everything depends on a quiet assumption that the Apache worker process servicing these tenants remains intact.

But that assumption is false. Two Polish researchers, Bartlomiej Dmitruk of Striga.ai and Stanislaw Strzalkowski of ISEC.pl, were able to crash the worker process and potentially take control of the server by transmitting two HTTP/2 frames in the wrong order.

The Apache Software Foundation shipped an emergency update to bring the version of Apache HTTP Server to 2.4.67 and close CVE-2026-23918, a double-free vulnerability in the mod_http2 module rated CVSS 8.8.

If you’re running version 2.4.66 on a shared host and haven’t yet applied this update, drop everything else.

If you’re running version 2.4.66 on a shared host and haven’t yet applied this update, drop everything else. The vulnerability exists in h2_mplx.c, the routine for cleaning up HTTP/2 streams within the mod_http2 module.

The researchers found that two callback functions of the nghttp2 library could execute consecutively and attempt to clean up the same stream object twice, thereby adding the same pointer to the list of objects to be cleaned. This represents a classic double-free condition.

The triggering event is almost embarrassingly simple. “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,” Dmitruk explained in a writeup published by The Hacker News.

No authentication is required, no special URL is accessed, and there are no apparent indications of a problem in the log files.

This constitutes a complete attack for purposes of denial of service. “One TCP connection, two frames, no authentication, no special headers, no specific URL, and the worker crashes,” Dmitruk told The Hacker News. All versions of Apache operating with a multithreaded MPM are therefore vulnerable.

The potential for remote code execution is less common, but considerably more severe. This depends on use of the mmap-based memory allocator by the Apache Portable Runtime. That is the default configuration for systems based on Debian and for official images of the httpd Docker container used extensively by the hosting industry without awareness of this dependency.

The researchers built a working x86_64 proof-of-concept exploit that leverages the fixed scoreboard address to gain control of execution. So the exploit isn’t theoretical.

The good news for old-school administrators: the MPM prefork model isn’t affected. If you continue to operate in this model, your refusal to modernize just paid off, at least this once.

Apache vulnerabilities tend to be bad in roughly proportional ways. A vulnerability in mod_php affects PHP. A vulnerability in a third-party module affects the user who loaded the module. The resulting damage remains well within the boundaries of the module.

mod_http2 is different. It operates within the worker process and therefore provides less protection than mod_php, mod_ruid2, and any multitenant isolation implemented by the host. If you can execute code within the worker process, you obtain access to the user privileges of the process and achieve complete read access to the web root directories of all tenants on the host.

This is exactly the opposite of the behavior for which the shared hosting model was designed: No tenant should access files belonging to another tenant.

CVE-2026-23918 puts the layer that enforces that boundary in scope for unauthenticated remote attackers. The PHP sandbox still does its job. The bug just goes around it.

For a medium-sized provider supporting a few thousand websites on about 100 individual hosts, this represents the worst-case scenario for system cleanup: not a customer concerned about slow system performance, but a customer asking why a phishing kit has been uploaded to their WordPress uploads directory.

Apache is no longer the dominant technology for the open web, because that position has been held by Nginx for several years. But Apache isn’t going anywhere either. According to W3Techs, Apache remains the third most widely used web server technology, with market share of approximately 24% as of April 2026.

That is a significant underestimate of the actual level of exposure to this vulnerability.

The shared hosting market remains a stronghold for Apache, and by a large margin. The cPanel and Plesk control panels that serve most of the budget hosting market default to Apache, and provisioning with WHM still results in Apache virtual hosts.

Legacy installations of WordPress maintained by small agencies continue to operate under Apache because that's the intended function of .htaccess. Consequently, the majority of multitenant shared servers remain exposed unless patched.

The period of vulnerability is also of concern. Proof of concept is available, and generation of a working DoS attack requires little effort. Expect widespread attempts at exploitation by the end of the week, or earlier.

Immediate action by providers using cPanel/WHM will be to migrate to the EasyApache 4 channel. Execution of yum update ea-apache24 (or of the equivalent command with dnf on AlmaLinux 9) will obtain version 2.4.67 after completion of the final build by the cPanel team.

Rebuilding images for providers using the official Docker base image for httpd will represent a more efficient alternative to in-place patching.

The greater challenge is to determine the appropriate course of action for systems that aren't patched. Industry watchers like Igor Seletskiy of CloudLinux have argued for years that the shared-hosting market contains so many opportunities for exploitation in 2026 that it's virtually impossible for a competent adversary to remain undetected.

A CVSS score of 8.8 for remote code execution within the process space is perhaps the best example of his point. Protection against subsequent lateral movement may be achieved with the use of CageFS on systems operating with CloudLinux, but compromise of the worker process itself can't be prevented.

Researchers like Rachel Sibley at the Shadowserver Foundation have flagged in past disclosures that the time interval between release of a patch and widespread exploitation of the vulnerability has been reduced to hours, and in many cases to minutes.

The developers of Apache responded promptly to this report and provided a fix. Most of the remaining period of vulnerability will be experienced by providers of low-cost shared hosting.