Sixty-four percent. That is the share of cloud environments Wiz found this week running a vulnerable version of Apache HTTP Server. If your web infrastructure runs Apache, there is a reasonable chance your servers are sitting on a hole that lets attackers run their own code on your machines.
The vulnerability is CVE-2026-119618. It lives in mod_http2, which is the Apache module that handles the HTTP/2 protocol. HTTP/2 is the modern version of the web’s core communication standard, used by most servers built in the last several years to deliver pages faster. The flaw is a race condition, meaning it appears when two requests hit the server at exactly the wrong moment, allowing an attacker to corrupt the server’s memory in a way that can enable arbitrary code execution. With a CVSS score of 9.8 out of 10, this is about as severe as vulnerabilities get.
What You Need to Do Right Now
Affected versions are Apache HTTP Server 2.4.55 through 2.4.70. The fix, version 2.4.71, was released on November 11th. If you are running anything in that range and HTTP/2 is enabled, upgrading today is the correct move.
There is one important caveat. The 64 percent exposure figure counts cloud environments with vulnerable server versions. It does not confirm that every one of those is actively exploitable, because HTTP/2 must be explicitly enabled for the flaw to be reachable. Servers configured to use only HTTP/1.1 are not affected. That said, Wiz also found that 51 percent of vulnerable environments had publicly exposed instances, so the real-world attack surface is not theoretical.
No confirmed exploitation has been reported yet. That window tends to be short. When a critical remote code execution vulnerability with a public CVE number hits a technology as widely deployed as Apache, working exploits typically surface within days.
If You Cannot Patch Immediately
If your team needs time to test the upgrade before pushing it to production, the interim step is to disable HTTP/2 support. Remove or comment out the h2 and h2c protocol identifiers from your Apache configuration, restrict public access while you prepare the patch, and check your logs for unusual HTTP/2 traffic patterns from the past week. After patching, do a second review to confirm the upgrade took effect across all running instances.
The Bigger Pattern
This vulnerability follows a pattern that shows up repeatedly in security incidents. Infrastructure components that have been running quietly for years, often the ones nobody actively monitors or updates, carry vulnerabilities that were never obvious at the time of deployment. Apache has powered the web for decades. That familiarity breeds a certain amount of complacency about keeping it current.
A regular patching cycle, combined with a clear inventory of what versions are actually running in your environment, is not an aspirational practice. It is the baseline. The organizations that move fast here are the ones that already know what they are running and can push an upgrade on short notice.
Want to explore how a proactive DevOps practice could help protect your business? Let’s talk.