Wiz published an advisory on November 11 for CVE-2026-119618, a critical race condition in the HTTP/2 module (mod_http2) of Apache HTTP Server. A remote, unauthenticated attacker can corrupt heap memory and reach arbitrary code execution. The commands run with the privileges of the web server process.

As of Wiz's publication, there is no public exploit and no reports of exploitation in the wild. I would not read that as a reason to wait. The fix is a version bump or a one-line config change.

What the bug is

The flaw sits in the assign_headers() function. Per Wiz, concurrent threads share resources there without proper synchronization. That lets an attacker trigger heap corruption, which can be turned into code execution.

Wiz says the bug was independently discovered by Anthropic and Google Cloud's Vulnerability Research Team. The article gives no CVSS score, only "critical, high-severity". Treat the exact score as not yet stated.

Affected and patched versions

Product Affected Patched
Apache HTTP Server 2.4.55 through 2.4.70 2.4.71 and newer
mod_h2 (standalone, GitHub) 2.0.8 through 2.0.42 "2.0.24 and newer" (see below)

The mod_h2 row is inconsistent in the source. The table lists the patched version as 2.0.24, which is lower than the top of the affected range. The remediation text says to move to a version newer than 2.0.42. I would follow the remediation text and go above 2.0.42. Then check the Apache release notes that Wiz links as its reference.

The issue applies to deployments that use HTTP/2. A server that never negotiates h2 or h2c is not exposed through this path.

How exposed you probably are

Wiz reports that 64% of cloud environments have resources vulnerable to CVE-2026-119618. 51% have publicly exposed instances. Wiz notes that these numbers do not take configuration into account, so the real exposure is lower. Anything with HTTP/2 on and a public listener is the first thing to fix.

The lateral-movement risk is the part I would worry about in containerized setups. Wiz points out that a compromised Apache instance in a containerized or virtualized workload can be an entry point to adjacent microservices or cloud metadata endpoints. An httpd container with a wide-open IAM role or reachable metadata service becomes a bigger problem than a single web server.

Fix order

  1. Upgrade Apache HTTP Server to 2.4.71 or later. This release addresses the race in assign_headers().
  2. If you build mod_h2 standalone from GitHub, upgrade past 2.0.42.
  3. If you cannot patch right away, disable HTTP/2. Wiz's suggested config restricts the protocol list to HTTP/1.1 by removing h2 and h2c references:
# Restrict protocols to HTTP/1.1
Protocols http/1.1

Put that in httpd.conf or whichever config file sets your Protocols directive. Remove any other h2/h2c entries, then reload.

What I would do

First, find every place httpd runs. Include sidecars, reverse proxies in front of app containers, and base images that bundle Apache. The 2.4.55 to 2.4.70 range is wide, so most current installs are likely inside it.

Second, if the upgrade needs a change window, apply the Protocols http/1.1 mitigation today and patch afterward. The cost is losing HTTP/2 multiplexing. For most internal services and many public sites that is a small price for a few days.

Third, if you run distribution-packaged Apache, check whether your vendor has shipped a fix. The source covers upstream version numbers only. It says nothing about backports under different version strings, so I would not assume a package reporting an older version is unpatched or patched without checking the vendor advisory.

The usual pattern with bugs like this is that the window between disclosure and a working exploit is short, especially when two independent research teams found the same flaw. No exploit is public today. Closing the HTTP/2 path now is cheap, and cleanup after exploitation is not.

Sources: