I read Apache advisories from the top of the security page, because the newest release sits there and the fix is usually the boring part. This week it was not. Apache released httpd 2.4.71 on November 11, 2026, fixing CVE-2026-119618, a race condition in mod_http2 that the project rates critical and Red Hat scores 9.8.
The bug is genuinely bad. What kept me on the page is that the fix exists in the httpd release and nowhere else. The advisory also names standalone mod_h2 2.0.8 through 2.0.42 as affected, and that repository was archived in June, four days after the last tag. There is no 2.0.43. Two write-ups told people to upgrade the module anyway.
🔍 What the Advisory Actually Says
Apache affects httpd from 2.4.55 through 2.4.70. Version 2.4.55 shipped on January 17, 2023, so the window is every release of the 2.4 branch for three years and ten months. Standalone mod_h2 is affected from 2.0.8 through 2.0.42.
Two teams found it: Anthropic’s OSS Scanner, reported October 26 as ANT-2026-MAPKT6MZ, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research, reported November 3. The fix landed as commit 824beab9b9424d6cfb29595248fdbf6c3dddeab1 on November 11. Sixteen days from the first report to a signed release, which is fast.
The same release carries two more fixes: CVE-2026-106023, an important NULL pointer dereference in mod_md that crashes child processes, and CVE-2026-109163, a one-byte stack overwrite in mod_vhost_alias rated low that only affects 2.4.69 and 2.4.70.
🧵 The Bug Is a Thread Writing Into Another Thread’s Memory
mod_http2 multiplexes many streams over one connection and spreads the work across worker threads. In assign_headers(), a worker writes request headers into stream data owned by the connection thread, through a shared allocator with no lock. Two threads touching one allocation without synchronization is a heap corruption primitive. Red Hat’s description is specific: one thread modifies memory belonging to another, and a remote unauthenticated attacker can turn that into command execution with the privileges of the httpd process.
The precondition is HTTP/2 itself, h2 over TLS or h2c in the clear, enabled through the Protocols directive. That directive can be set server-wide or inside a single virtual host, so the setting to check is not one line in one file. HTTP/1.1-only servers are not affected.
The recent history of the same module is what makes this feel like a pattern. CVE-2026-23918 was a double free on early stream reset, fixed in 2.4.67 in May. CVE-2026-57941 was a use-after-free through shared session->bbtmp re-entrancy, fixed in 2.4.69 on October 1. Both are memory-safety failures in concurrent stream handling, the same neighborhood as this one. If you upgraded to 2.4.67 and then to 2.4.69, you were running a version affected by this one the whole time.
📦 Three Vendors, Three Instructions, One Impossible
Apache names mod_h2 2.0.8 through 2.0.42 as affected. Write-ups then have to tell readers what to do about it.
Wiz’s analysis lists mod_h2 as patched at “2.0.24 and newer” in its table, which cannot be right, since 2.0.24 is inside the affected range it also lists, while its body text says to upgrade the module to a version newer than 2.0.42. Upwind says to upgrade mod_h2 to 2.0.43. OX Security gets it right: no fix, repository archived, move to httpd 2.4.71.
The repository is icing/mod_h2. Its release list ends at v2.0.42, published May 29, 2026, and the project is archived, with its last push on June 9, 2026. There is no 2.0.43 to upgrade to. For a few hours after each post went up, that was the advice people were acting on.
I understand why. Remediation gets written from the affected-versions block, and that block describes a project that no longer ships releases. But the only executable path for a standalone build is the upstream commit, 824beab, or turning HTTP/2 off. That is a different job than a package upgrade, and not one most teams are set up to do quickly.
The structural lesson is that archiving a repository does not retire the code. mod_h2’s guts were merged into httpd, the GitHub project went read-only, and the CVE still got assigned to the module name. A CVE outlives the repository that produced it, and nobody owes you a patched tag for a project that stopped shipping.
🌡️ Severity Is a Property of Your Build
Red Hat’s page is the most useful document in the set, and not because of the number. It scores the flaw 9.8: network, low complexity, no privileges, no interaction, full impact on confidentiality, integrity, and availability. Then it explains why its own rating is lower. The mod_http2 packages in RHEL 9 and RHEL 10 allocate each HTTP/2 stream from a separate allocator, which removes the shared-allocator primitive and makes exploitation substantially harder. The statement calls the issue critical while the per-product rating is Important. RHEL 8 and earlier are unaffected, because the vulnerable code arrived in 2.0.8.
Same CVE, same week, different answers. Amazon Linux scores it 9.8 critical and lists Amazon Linux 2 Core, Amazon Linux 2023, and the 2027 Preview as pending fix. Ubuntu published its page on November 12 with priority High and every release from 14.04 trusty through 26.10 stonking needing evaluation. Debian lists bookworm, trixie, and forky as vulnerable, with 2.4.71-1 recorded as the fixed version in unstable.
Ubuntu’s page has the note worth reading twice: newer module versions have been backported into stable releases, so the upstream range of 2.0.8 through 2.0.42 does not map onto Ubuntu’s package versions. That is the general problem with a version range as a risk statement. It describes upstream history, not your disk.
Wiz adds scale with the caveat attached: 64 percent of cloud environments have resources matching the vulnerable versions and 51 percent have publicly exposed instances, and the figure does not take configuration into account. It cannot, because HTTP/1.1-only deployments are unaffected. Treat it as an upper bound on who should check, not a count of who is exploitable.
💥 What “Exploit Available” Means Right Now
Red Hat’s statement contains the strongest sentence in the public record: public research has demonstrated a reliable exploit against a default-configured server with the module enabled. It does not name that research or link it.
Everything else points the other way. SANS Internet Storm Center’s November 12 podcast says no working exploit has been made public. Wiz, publishing the same day as Red Hat, says no exploit is available and no exploitation in the wild has been reported. Horizon3 has the most precise accounting: a third-party proof of concept published November 12 reproduces the heap corruption on 2.4.70 under memory and thread sanitizers and reports a clean result on 2.4.71, but it does not demonstrate code execution, and its author is unaffiliated with either reporting team. The flaw is not in CISA’s Known Exploited Vulnerabilities catalog.
So the corruption primitive is reproducible by an outsider within a day of disclosure. Weaponized code execution is not public. Nobody has reported exploitation. Red Hat’s claim may be true and I cannot check it, which is why I am calling it a claim.
One operational detail: you cannot safely confirm this by hand. Triggering the race corrupts memory and takes down worker processes, so a test request against production is a self-inflicted outage. Confirmation means version plus HTTP/2 negotiation, which is all a scanner can give you.
🛠️ What I’d Actually Check
Whether you speak HTTP/2 at all. Apache’s advisory offers no workaround, so the mitigation everyone quotes comes from Wiz: remove h2 and h2c from Protocols, leaving Protocols http/1.1. That has to cover the server-wide setting and every virtual host, including the ones in included files nobody remembers.
What you are actually running. If httpd came from a distribution, the 2.4.x number on disk is not the upstream version. Use the vendor advisory instead: RHSA-2026:98981 for RHEL 9, RHSA-2026:98978 for RHEL 10, the Debian tracker for bookworm, trixie, and forky, and Canonical’s page once it stops saying needs evaluation.
Whether you vendored mod_h2. If you build the module standalone, there is no release to pull. Patch from 824beab or disable HTTP/2.
Restart. A fixed module on disk changes nothing in a running process, and an httpd that has been up since before the upgrade is still serving the old code.
🧠 Final Thoughts
Sixteen days from an AI scanner’s report to a signed Apache release is a good number and I do not want to bury it. The discovery side is fast, and the project responded at a pace that would have been unusual two years ago.
The slow part is distribution. The patch landed in one artifact, and a slice of the installed base cannot consume it, either because their distribution has not packaged it or because they build the module from a repository that stopped shipping five months ago. Then the advice, written fast by people who are paid to be first, told some of them to upgrade to a version that does not exist.
So the takeaway is narrower than patch your Apache. Check Protocols first, because that question has an answer today regardless of what your package manager says. Read the vendor advisory for your build rather than the CVE record, because severity here is a function of someone’s allocator. And if you write this guidance for a living, go confirm the fixed version you are about to print exists. It takes ten seconds. Two major vendors skipped them this week.
Thanks for reading.