Apache HTTP Server 2.4.71, released on Nov 11, 2026, fixes CVE-2026-119618, a critical remote code execution flaw in the mod_http2 module that affects versions 2.4.55 through 2.4.70, according to SecurityWeek. If you run Apache with HTTP/2 turned on, whether on a VPS, a WordPress host or a self-hosted stack, an attacker who needs no login can potentially run commands on your server.
The fix is a single upgrade. If you can't upgrade today, you can turn HTTP/2 off as a stopgap.
What CVE-2026-119618 does
The bug is a race condition in the assign_headers() function of mod_http2. Wiz's write-up says a remote, unauthenticated attacker can corrupt heap memory and achieve arbitrary code execution, with commands running under the web server process's privileges.
Apache describes the root cause as shared resources used without proper locking, per CybersecurityNews. Ostorlab explains that mod_http2 writes a synthetic Content-Length header into a table that is shared with the connection thread. Threat Landscape places the code in modules/http2/h2_request.c and classifies it as CWE-362.
Red Hat assigned it a CVSS score of 9.8, SecurityWeek reports. Threat Landscape says the Apache Software Foundation rated it Critical, and lists a CVSS v3.1 base score of 9.8.
Two teams found it independently. Threat Landscape says Anthropic's OSS Scanner reported it on 26 Oct 2026, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it on 3 Nov 2026.
Am I affected? Three questions
1. Is HTTP/2 enabled? This is the deciding factor. Red Hat is quoted by SecurityWeek as saying only HTTP/2-enabled servers are affected, and servers serving only HTTP/1.1 are not vulnerable. Look through your Apache configuration, including virtual host files, for a Protocols line that lists h2.
2. Which version are you running? Upstream Apache 2.4.55 through 2.4.70 is affected; 2.4.71 and newer is fixed.
3. Did your Linux distro backport the fix? Distributions often patch older version numbers rather than shipping 2.4.71, so the version string alone can mislead. Ostorlab reports that Red Hat shipped backports on 2026-11-11, and lists Debian advisory DSA-6620-1 with a fixed apache2 package. Check your distro's security advisory for the exact fixed package version rather than comparing against 2.4.71.
If HTTP/2 is handled by a reverse proxy in front of Apache, and that proxy forwards plain HTTP/1.1, Apache itself isn't speaking HTTP/2 and isn't exposed through this path.
How to fix it, and what to do if you can't yet
Ostorlab's write-up covers these fixes and workarounds:
- Install your distro's fixed package.
- Build from the 2.4.71 source tarball.
- Disable HTTP/2 until you can patch.
- Put a reverse proxy that terminates HTTP/2 and forwards HTTP/1.1 in front of Apache.
If you go the disable route, remove h2 from every Protocols line in your configuration, including virtual host files, so that no line still lists it. Then repeat the search from question 1 above: if no Protocols line lists h2, you've covered every place it was enabled. Clients will fall back to HTTP/1.1. As the SQMagazine quote says: "Patch now or drop h2 until you can."
Upgrading covers all three.
Is anyone exploiting it?
The reports don't line up. As of Nov 12, Ostorlab says no public exploit code is linked, no in-the-wild use is known, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog. The same page relays Red Hat saying public research demonstrated a reliable exploit against a default-configured server with mod_http2 enabled. OffSeq's summary mentions public proof-of-concept repositories, and CVE Playground notes the reporting is inconsistent.
The fair reading: no confirmed exploitation in the wild as of Nov 12, but exploit research exists. That's reason enough to patch now.
How widespread is exposure? Wiz says 64% of cloud environments it sees have vulnerable resources and 51% have publicly exposed instances. That's Wiz's own telemetry, not an independent count.
What to watch next
Keep an eye on CISA's KEV catalog. If CVE-2026-119618 is added, that means confirmed exploitation in the wild, and any HTTP/2-enabled server still on 2.4.70 or earlier should be treated as a likely target.
