Apache Patches Critical HTTP/2 Remote Code Execution Flaw

By Daniel Okafor

Apache has shipped a fix for CVE-2026-119618, a critical remote code execution flaw in mod_http2 affecting HTTP Server versions 2.4.55 through 2.4.70. Wiz telemetry says 64% of cloud environments it monitors hold vulnerable resources. Roughly half of those instances sit exposed to the public internet. That is the headline. The caveats come next.

What exactly was fixed?

The flaw is a race condition in the mod_http2 module, specifically in the assign_headers() function. Concurrent threads share a resource without proper synchronization. The result is heap memory corruption. An unauthenticated attacker who triggers it can execute arbitrary code with the privileges of the web server process.

Anthropic's OSS Scanner and Google Cloud's Vulnerability Research teams found the bug independently. Apache describes it plainly: "Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers() can lead to RCE."

The affected range is wide but bounded:

• Apache HTTP Server 2.4.55 through 2.4.70
• Standalone mod_h2 version 2.0.8 through 2.0.42
• Any deployment with HTTP/2 explicitly enabled

That last bullet matters more than most coverage admits.

Is your server actually exposed?

Probably not, if you changed nothing. HTTP/2 is disabled by default in Apache HTTP Server. The 64% figure from Wiz counts vulnerable versions, not vulnerable configurations. Wiz itself concedes the numbers do not account for whether HTTP/2 is switched on. An organization running 2.4.68 with default settings is running vulnerable code that cannot be reached through this path.

Researchers at watchTowr confirmed the exploitability conditions and issued a blunt recommendation: "patch now or drop h2 until you can." That is sound advice. It is also the only advice available, because no exploit exists in public today.

Wiz assesses severity as critical. No CVSS score has been published yet, which is unusual for a flaw carrying this label. The company states it is "currently unaware of any public exploits or attacks targeting the flaw, but this could change soon." Treat that as a window, not a guarantee.

How big is the blast radius?

Apache HTTP Server backs roughly one in five websites, according to estimates cited in the disclosure coverage. That is a very large denominator. Even a small fraction of misconfigured instances represents thousands of internet-reachable targets.

Wiz researchers explain the mechanics directly: "Due to improper synchronization when executing concurrent threads sharing resources, an attacker can trigger heap corruption." They add that "this memory corruption can ultimately be leveraged to achieve RCE on the hosting server, allowing unauthorized threat actors to execute arbitrary commands with the privileges of the web server process."

Note the limit. The code runs as the web server process, not as root. That still permits webshell deployment, lateral movement, and data theft from anything the process can read. Privilege separation reduces impact; it does not eliminate it.

What else is in the update?

The latest Apache HTTP Server release patches two additional vulnerabilities:

• CVE-2026-106023 — a null pointer dereference in mod_md
• CVE-2026-109163 — a low-severity data overwrite flaw in mod_vhost_alias

Neither carries RCE potential. Both ride along with the same upgrade, so there is no reason to defer patching for their sake.

What should CIOs do now?

Inventory first. Identify every Apache instance across on-prem and cloud estates, then check versions against the affected ranges. Second, check whether HTTP/2 is enabled; grep the configuration for Protocols and h2 directives. Third, upgrade to the fixed release on every instance, exposed or not.

If a patch cycle takes weeks, disable HTTP/2 in the interim. watchTowr's advice applies to any team that cannot patch this week. Falling back to HTTP/1.1 carries a performance cost on high-connection workloads. That cost is temporary and survivable; heap corruption is neither.

The absence of observed attacks is a data point about the past, not the future. Race-condition exploits take time to weaponize reliably. Public proof-of-concept code, once released, compresses that timeline sharply. Patch before the clock, not after it.