Research

Apache httpd mod_http2 CVE-2026-119618 (9.8): Update to 2.4.71 or Turn Off HTTP/2. Red Hat Says a Reliable Exploit Is Public, Wiz Says None Exists. Here Is What Each Actually Wrote

Patrick Duggan · · 6 min read

Apache httpd mod_http2 CVE-2026-119618 (9.8): Update to 2.4.71 or Turn Off HTTP/2. Red Hat Says a Reliable Exploit Is Public, Wiz Says None Exists. Here Is What Each Actually Wrote

If you run Apache HTTP Server 2.4.55 through 2.4.70 with HTTP/2 turned on, update to 2.4.71 or your distribution's fixed package now. If you cannot update today, take HTTP/2 off: remove h2 and h2c from every Protocols line so it reads "Protocols http/1.1", in the main config and in every virtual host, then restart. Servers that only speak HTTP/1.1 are not affected, according to Red Hat. Red Hat Enterprise Linux 8 and earlier are not affected. The flaw is not in CISA's Known Exploited Vulnerabilities catalog as of version 2026.11.10.

What Apache says

Apache's own advisory, which we read directly, rates CVE-2026-119618 critical. Its title: "mod_http2: heap corruption and RCE in assign_headers". Its description, in full: "Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers() can lead to RCE."

  • Affected: "Apache HTTP Server: from 2.4.55 through 2.4.70", and "Affected releases of mod_h2 from GitHub: from 2.0.8 through 2.0.42."
  • Fixed: 2.4.71, released November 11, 2026.
  • Found by: two teams independently. Anthropic's OSS Scanner reported it on October 26; Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it on November 3.
  • Workaround: Apache's entry gives none. It says nothing about exploitation either way.

Where Red Hat and Wiz disagree

This is the part that matters for how fast you move, so here are both, word for word.

Red Hat rates it Critical, CVSS 3.1 base score 9.8, vector AV:N/AC:L/PR:N/UI:N: over the network, no account, no user action. Its statement says: "public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled. Successful exploitation allows an attacker to execute arbitrary commands, gain full control of the server process, and access or modify sensitive information." Red Hat does not name or link that research.

Wiz, in a post by Merav Bar dated November 11, says: "As of the time of this blog's publication, no exploit is available and there are no reports of exploitation in the wild."

Both can be honest at once. They may mean different things by "exploit": a demonstration that the heap can be corrupted on demand is not the same as a working tool that runs an attacker's commands. Red Hat may also have seen research that Wiz had not. Neither page says which. What we can add is one dated fact. A public GitHub repository named for this CVE, googlesky/CVE-2026-119618, was created at 05:05 UTC on November 12, after Wiz's post. We read its README; we did not run its code. It describes a lab that "reproduces the corruption on httpd 2.4.70" and proves the race with ThreadSanitizer, and it lists the impact as "Heap corruption in an httpd child process; potential remote code execution". That is a crash proof in public, not a published code-execution exploit. It also means the exact trigger is now public, which shortens the time to a working one.

So: Wiz's "no exploit" was accurate for what was public when Wiz wrote it, as far as we can tell. Red Hat's "reliable exploit" is a claim we could not trace to any public source. Patch as if Red Hat is right.

Why Red Hat 9 and 10 are rated lower

Red Hat explains the root cause: "a worker thread writes into memory owned by the connection thread through a shared, lock-free allocator." Its own mod_http2 packages for RHEL 9 and 10 "allocate each HTTP/2 stream from a separate allocator, which substantially increases the complexity of exploiting the flaw", so those are rated Important, not Critical. Harder is not safe. Red Hat shipped fixes for both on November 11.

Package status, from the trackers we read

  • Red Hat (security data API, published November 11): RHEL 10 fixed in mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978). RHEL 9 fixed in mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981). Separate errata cover RHEL 10.0 and 10.2 EUS, RHEL 9.6 and 9.8 EUS and RHEL 9.4 for SAP. RHEL 6, 7 and 8: not affected. Red Hat Hardened Images (httpd) and JBoss Core Services (jbcs-httpd24-mod_http2): listed as affected, with no fix yet in the data we read.
  • Debian (security tracker): trixie fixed in 2.4.71-1~deb13u1 via DSA-6620-1. Unstable (sid) fixed in 2.4.71-1. Forky, at 2.4.69-1, is listed as vulnerable. Bookworm is listed as vulnerable, although the tracker shows a bookworm security version of 2.4.71-1~deb12u1. That looks inconsistent, so check your installed version rather than trusting the label.
  • Ubuntu: we could not read Ubuntu's CVE page; it returned a gateway timeout twice. Check ubuntu.com/security/CVE-2026-119618 yourself.
  • Standalone mod_h2 from GitHub: Apache names 2.0.8 through 2.0.42 as affected. Wiz's post gives two different fixed versions in two places. Upgrade past 2.0.42 and confirm against the mod_h2 releases page.

What to do

  1. Find your version. On most Linux systems "apachectl -v" or "httpd -v" prints it. On Debian and Ubuntu, check the apache2 package version; on Red Hat, check the mod_http2 package version, because Red Hat backports fixes without changing the httpd version number.
  2. Find out whether HTTP/2 is on. Loading the module is not enough by itself: Apache's mod_http2 documentation says "You must enable HTTP/2 via Protocols". Search your configuration, including every included file and virtual host, for a Protocols line containing h2 or h2c. "apachectl -M" shows whether http2_module is loaded at all.
  3. Update to httpd 2.4.71, or to your distribution's fixed package listed above, and restart Apache.
  4. If you cannot update yet, set "Protocols http/1.1" everywhere h2 or h2c appears and restart. This is Wiz's interim advice, and Red Hat states HTTP/1.1-only servers are not affected. The cost: clients fall back to HTTP/1.1, which is slower but works.
  5. Do not forget Apache that you did not install on purpose: appliances, control panels, container base images and vendor products that bundle httpd. Ask the vendor if you cannot check.
  6. A reverse proxy or CDN in front of Apache does not settle this on its own. Whether it passes HTTP/2 through to Apache depends on how it is set up; check the hop between it and your server.

What is not known

Whether anyone is exploiting this. Wiz says no reports; Apache and Red Hat say nothing about attacks; CISA's catalog does not list it. Whether a working code-execution exploit exists: Red Hat says public research shows one, and we could not find it. How many servers are exposed: Wiz says 64% of the cloud environments it monitors have vulnerable resources and 51% have publicly exposed instances, but its own post says those figures "do not take configuration into account", so they count Apache versions, not servers with HTTP/2 turned on. The real exposed share is lower by an amount nobody has published.

How we know, and how we checked

We read Apache's security page, Red Hat's CVE page and its security data API, Wiz's post, Apache's mod_http2 documentation and the Debian security tracker, plus The Hacker News report of November 12. We read the README of the googlesky repository on GitHub and ran none of its code. We tested nothing and run no vulnerable build.

We checked CISA's catalog in its JSON form: version 2026.11.10, released November 10 at 19:03 UTC, 1,779 entries. CVE-2026-119618 is absent. Four older Apache HTTP Server flaws are in it; this one is not. That version predates Apache's release, so watch for an update.

We checked our own edge. Our ttp-check tool scanned, from October 13 to today, 327,067 edge block events, 51,977 edge decoy hits and 714 origin honeypot captures, and found zero matches. Read that zero carefully. The only fingerprint our exploit harvester could extract from the one public repository was a log file path from its lab, which says nothing about the attack itself. And this flaw lives in how HTTP/2 frames and headers are handled inside a connection; our instruments record request paths, not HTTP/2 framing or header tables. So this is a blind spot, not a clean result: we cannot tell you whether anyone is trying it.

We add no indicators to our feed. None of the sources publishes an IP address, domain or file hash: none published in the sources we read.

Sources

Apache HTTP Server, "Apache HTTP Server 2.4 vulnerabilities," entry for CVE-2026-119618, httpd.apache.org/security/vulnerabilities_24.html. Red Hat Customer Portal, CVE-2026-119618, access.redhat.com/security/cve/cve-2026-119618, and the Red Hat Security Data API record for the same CVE, public date November 11, 2026. Wiz, Merav Bar, blog post on CVE-2026-119618, November 11, 2026, wiz.io/blog/cve-2026-119618-rce-apache-http-server-vulnerability. Apache HTTP Server documentation, mod_http2. Debian security tracker, CVE-2026-119618, and DSA-6620-1. CISA Known Exploited Vulnerabilities catalog, JSON feed, version 2026.11.10. GitHub repository googlesky/CVE-2026-119618, README, read November 12, 2026. The Hacker News, Swati Khandelwal, November 12, 2026.

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register