Apache Patches a Critical mod_http2 RCE Found Independently by Anthropic’s Scanner and Google Researchers, but 2.4.70 Shipped Nearly Five Days Earlier Without the Fix and the One-Line Patch Was Public for About 58 Hours Before the Advisory

Apache released HTTP Server 2.4.71 on November 11 to fix CVE-2026-119618, a critical race condition in mod_http2, the module that serves HTTP/2. Apache says the flaw “can lead to RCE.” Red Hat says a remote attacker who can reach the server could run commands without authentication, and that servers configured to serve only HTTP/1.1 are not vulnerable. Apache lists httpd 2.4.55 through 2.4.70, plus releases 2.0.8 through 2.0.42 of the standalone mod_h2 module, as affected. Two finders reported it eight days apart: Anthropic’s OSS Scanner on October 26, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research on November 3. SecurityWeek and Wordfence have covered the headline.

The primary records add four things the coverage leaves out. Version 2.4.70, posted on November 6, still contains the bug. The fix is a one-line change that Apache merged into its public GitHub repository on November 9, under the title “mod_http2: assign_headers update table,” about 58 hours before the advisory went out. The standalone mod_h2 project that the advisory also lists is archived on GitHub, and its last release, 2.0.42, sits inside the affected range. And the vendors do not agree on how bad it is: Red Hat rates it Critical overall but only Important on RHEL 9 and 10, Ubuntu’s tracker says High, and NVD has no score yet.

Nothing we read says the flaw has been used in an attack. At 19:30 UTC on November 12 it was not in CISA’s Known Exploited Vulnerabilities catalog (version 2026.11.10, the newest), FIRST’s EPSS service gave it a probability of 0.4 percent, and NVD’s status was Awaiting Analysis. The sources do disagree about whether an exploit exists, which we set out below. The practical test is short: does your Apache offer HTTP/2 on a threaded MPM, and is the installed build fixed? Distribution builds carry their own version numbers, so the second answer cannot be read from httpd -v alone.

What Apache’s advisory says

Apache’s security page for 2.4, its post to the oss-security list and the CVE record carry the same description: “Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server’s mod_http2 in assign_headers() can lead to RCE.” The rest of the facts fit in a table.

Apache’s own documents differ on credit. The advisory page and the oss-security post name both finders, while the CHANGES file shipped with 2.4.71 lists only “Anthropic’s OSS Scanner, as vulnerability ANT-2026-MAPKT6MZ” for this entry.

The timeline: 2.4.70 shipped without the fix, and the patch was public first

Times are UTC. The report dates come from Apache’s page and the CVE record; the other entries are timestamps on GitHub, Apache’s download servers and the Openwall archive.

• 2.4.70 still has the bug. Its tarball is stamped November 6 on Apache’s archive server, 11 days after the first report, and Apache’s page lists no security fixes for it. We read modules/http2/h2_request.c at the 2.4.70 and 2.4.71 tags: the line the patch changes is present in 2.4.70 and changed in 2.4.71. Anyone who updated on November 6, or pulled a container tagged 2.4.70 (Docker’s repository moved to 2.4.70 later that day), is on an affected build.
• The patch was public before the advisory. Pull request 975 is titled “mod_http2: assign_headers update table” and has no description; pull request 977, “[2.4.x] Merge changes to mod_http2,” only names the trunk commit. Neither carries a label or a comment. That is about 56 hours before the 2.4.71 tarball and about 58 hours before the advisory email. Apache’s page shows an earlier and longer gap: it dates the fix for CVE-2026-23918 to December 11, 2025 and the release that shipped it, 2.4.67, to May 4, 2026. We found no statement from the project on why the commit landed when it did, and nothing we read says anyone used it to build an exploit.
• The finders overlapped. Google’s report came eight days after Anthropic’s, and 2.4.71 came 16 days after the first. Our reading: a scanner and two human researchers reached the same bug within eight days, so it was findable. Nothing we read says anyone else had found it.

What the patch changes

The 2.4.x commit, 824beab (a cherry-pick of trunk commit 5ed3928), changes one line in modules/http2/h2_request.c. Our reading of the 2.4.70 and 2.4.71 sources is that assign_headers first copies the request’s headers into a table allocated for the request, and that one branch afterwards wrote a header into the original table instead of the copy; 2.4.71 writes to the copy. That fits Red Hat’s root-cause statement: “a worker thread writes into memory owned by the connection thread through a shared, lock-free allocator.” The function name is a useful check on Apache’s range. We found no assign_headers in the 2.4.54 file, and it appears in the 2.4.55, 2.4.70 and 2.4.71 files, which matches an affected range that starts at 2.4.55. We did not try to trigger the bug and we are not describing how it could be triggered.

Who is exposed

HTTP/2 has to be switched on

Apache’s default is HTTP/1.1. The documentation for the Protocols directive says “By default, only the http/1.1 protocol (which includes the compatibility with 1.0 and 0.9 clients) is allowed,” and the mod_http2 page says “You must enable HTTP/2 via Protocols in order to use the functionality described in this document.” Red Hat’s record says “Only servers that have HTTP/2 enabled are affected; servers configured to serve only HTTP/1.1 are not vulnerable.” Because Protocols is valid in the server config and inside a virtual host, one server can offer HTTP/2 on some sites and not on others. Wordfence adds a caution for anyone behind a CDN or load balancer: “A public site may serve HTTP/2 through a CDN, load balancer, or nginx while its Apache origin receives HTTP/1.1,” so the check has to be made at the Apache origin.

The MPM has to be a threaded one

Red Hat’s record explains that the module hands concurrent HTTP/2 requests to multiple threads, and the race is between those threads. The 2.4.71 source, in h2_c2.c, treats the event and worker MPMs (and a few others) as supported and marks prefork as not, with a comment that prefork’s use case is “running single-thread app engines like php.” On an unsupported MPM the module declines to offer HTTP/2 and logs a warning that the MPM “is not supported by mod_http2” and that “the HTTP/2 protocol will be inactive.” That is our reading of the source; we did not run a prefork server.

The version number does not settle it

Apache’s range is for upstream releases, and vendors move modules on their own schedules. Red Hat ships mod_http2 as a separate package, so RHEL 9 and 10 are fixed by package versions 2.0.26-7.el9_9.1 and 2.0.29-5.el10_3.1 rather than by an httpd number, and Red Hat says RHEL 8 and earlier are not affected, noting that “Versions of mod_http2 prior to 2.0.8 do not contain the affected code.” Ubuntu’s security team wrote in its tracker that “newer versions of the module have been backported to stable releases in Ubuntu,” so an old httpd number there does not rule the module out. Wordfence says it in general terms: “Vendors can backport module code or security fixes, so the Apache version number alone may not establish whether a vendor-supplied build is affected or patched.” Our Brotli report found the same pattern, one CVE with several vendor ratings and exposure that followed the code path rather than the version.

Wiz reports that 64% of cloud environments in its data have resources vulnerable to CVE-2026-119618 and that 51% have publicly exposed instances, with its own note that “this does not take configuration into account.” Read those figures as an upper bound on version exposure, not a count of exploitable servers.

Exploit status and severity: where the sources differ

Three outside statements about exploitation do not fully agree, and the last row is our own check of the public records.

The severity labels differ too. Apache calls the flaw “critical” in words, and its CVE record has no CVSS score. Red Hat, SUSE and Amazon Linux each publish a CVSS v3 base score of 9.8, and Red Hat’s vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Yet Red Hat rates its own RHEL 9 and 10 packages Important because they “allocate each HTTP/2 stream from a separate allocator, which substantially increases the complexity of exploiting the flaw.” Ubuntu’s tracker says Priority: high with the note “This is a remote RCE.”

Vendor and distribution status at 19:30 UTC on November 12

Trackers lag the vendors they track, so treat this table as a snapshot and follow each vendor’s own advisory.

The standalone mod_h2 project is archived at an affected release

Apache lists mod_h2 releases 2.0.8 through 2.0.42 from GitHub as affected. The GitHub project is marked archived, its last push was June 9, and its newest tag, v2.0.42, is the last version in that range. Wiz’s post tells readers who manage standalone builds to “upgrade the module to a version newer than 2.0.42,” but no such version exists there, and its own table lists the patched mod_h2 as “2.0.24 and newer,” a number lower than the last affected release. The Azure Linux maintainers, who are moving their mod_http2 package to 2.0.42 plus a patch, wrote in a pull request that the module is now maintained only inside httpd, “so there will be no newer standalone release.” Anyone who builds mod_h2 from GitHub for an older httpd needs a vendor patch or a move to httpd 2.4.71, which carries its own copy of the module.

A fifth mod_http2 advisory in 2026

Apache’s page lists an advisory that names mod_http2 or HTTP/2 under each of the four 2026 releases that carry security fixes: CVE-2026-23918 in 2.4.67 (a double free with “possible RCE”), CVE-2026-49975 and CVE-2026-48913 in 2.4.68, CVE-2026-57941 in 2.4.69 and now CVE-2026-119618 in 2.4.71. Two credits involve AI-assisted work: the CVE-2026-49975 finder is listed as “Quang Luong of Calif.IO in collaboration with OpenAI Codex,” and this report came from Anthropic’s OSS Scanner. We covered the scanner’s launch, including Anthropic’s statement that its output is model-generated and not reviewed by a person before it is emailed to maintainers. Whatever review this report had before it reached Apache, it held up: Apache rates it critical and Google’s researchers found the same flaw. Our report on curl 8.23.0 covers another HTTP/2 use-after-free that Anthropic is credited with.

What to do

Find out whether Apache offers HTTP/2

Two things have to be true at once: the module is loaded on a threaded MPM, and a Protocols line offers h2 (HTTP/2 over TLS) or h2c (cleartext). On the server, apachectl -M lists the loaded modules (Apache’s httpd documentation describes -M as “Dump a list of loaded Static and Shared Modules”), and a recursive grep finds the Protocols lines in the default configuration folders. Use apache2ctl on Debian and Ubuntu.

# Apache HTTP Server 2.4: which modules and MPM are loaded?
apachectl -M | grep -Ei 'http2|mpm_'

# Which Protocols lines offer h2 or h2c? (Debian and Ubuntu: /etc/apache2; RHEL family: /etc/httpd)
grep -RInE '^[[:space:]]*Protocols[[:space:]].*\bh2c?\b' /etc/apache2 /etc/httpd

We ran the same grep inside a throwaway tree of sample files, with the relative paths etc/apache2 and etc/httpd in place of the absolute ones, and it printed only the lines that offer HTTP/2, skipping a commented line, ProtocolsHonorOrder and a Protocols http/1.1 line:

etc/apache2/sites-enabled/a.conf:3:    Protocols h2 http/1.1
etc/httpd/conf.d/h2.conf:1:Protocols h2 h2c http/1.1

From outside, an ALPN test shows whether a TLS listener offers HTTP/2. With OpenSSL 3.x (we used 3.5.7 on Windows 11 in Git Bash), the line it prints is ALPN protocol: h2 when HTTP/2 is offered and ALPN protocol: http/1.1 when it is not. Point it at the Apache origin itself, because a CDN or load balancer answers for itself, and note that it cannot see h2c, which is why the config grep matters.

echo | openssl s_client -connect www.example.com:443 -servername www.example.com -alpn h2,http/1.1 2>/dev/null | grep -a "ALPN protocol"

We ran it against sxz.io and httpd.apache.org, and both printed ALPN protocol: h2. Against two local openssl s_server stand-ins, one started with -alpn http/1.1 and one with -alpn h2,http/1.1, it printed ALPN protocol: http/1.1 and ALPN protocol: h2. Those stand-ins are not Apache; they only show what each answer looks like.

Check that the installed build is fixed

• Source builds, containers and Windows builds: httpd -v should report 2.4.71 or later. The 2.4.71 tarball’s SHA-256 is 2bc5da5a33c247341de082717d4ebcb5cb49e8b73a05b7fddf7d5d6dc2f8de62, which matches Apache’s checksum file and the value pinned in Docker’s Dockerfile.
• RHEL 9 and 10: rpm -q mod_http2 should print mod_http2-2.0.26-7.el9_9.1 or later (RHEL 9) or mod_http2-2.0.29-5.el10_3.1 or later (RHEL 10), each followed by the architecture. Other streams are listed in Red Hat’s advisories.
• Debian 13 (trixie): dpkg-query -W apache2 should print 2.4.71-1~deb13u1 or later. For bookworm and for Ubuntu, follow the vendor’s advisory when it appears, because the trackers above show no fixed version.
• After any update: restart Apache. Wordfence tells hosting customers to ask providers to confirm that Apache was restarted after the update, and Apache documents the graceful form as apachectl -k graceful on its stopping and restarting page.

We could not run the package queries on a Linux host here, so the version strings come from Red Hat’s and Debian’s records, not from a test.

If you cannot patch yet

Take h2 and h2c out of every Protocols line that offers them, in the server config and in each virtual host. Wiz’s mitigation is the same change, and Red Hat says servers serving only HTTP/1.1 are not vulnerable. Restart Apache, then repeat the ALPN test above and expect ALPN protocol: http/1.1. We did not apply this change to a running Apache, so the one-line edit rests on Apache’s documentation and the vendors’ advice.

# Apache HTTP Server 2.4, in httpd.conf or inside each <VirtualHost>
# Before: HTTP/2 offered
Protocols h2 http/1.1

# After: HTTP/2 off until the fixed build is installed
Protocols http/1.1

If a host runs Apache for you

Updating WordPress, a plugin or a security plugin cannot patch the web server. Wordfence suggests asking the host whether its Apache accepts h2 or h2c and whether CVE-2026-119618 is fixed in the installed package, and asking for confirmation of the restart.

What nobody has said yet

• Whether anyone attacked the flaw before the patch. No source we read says so, and Wordfence notes that Apache “has not published a complete list of parties notified before disclosure.”
• Which “public research” Red Hat means. Its record does not link to it.
• Whether Ubuntu’s stable releases are affected through backported module code. Its tracker still reads needs-triage.
• Why 2.4.70, which shipped 11 days after the first report, did not carry the fix.
• When Debian bookworm, Amazon Linux and SUSE fixes will ship, and whether NVD and CISA will add scores or a Known Exploited Vulnerabilities entry.

What we checked

We read SecurityWeek’s report and Wordfence’s advisory (through its RSS feed, because its page answers scripts with a bot-check response); Apache’s 2.4 security page, the oss-security post and the CHANGES file for 2.4.71; the CVE record; NVD; Red Hat’s CVE data; the Debian, Ubuntu, SUSE, Amazon Linux, Alpine and Gentoo trackers; Docker Hub and the docker-library repository; Wiz’s post; CISA’s KEV feed; and FIRST’s EPSS API. On GitHub we read pull requests 975 and 977, the two commits, the h2_request.c file at the 2.4.54, 2.4.55, 2.4.70 and 2.4.71 tags, the icing/mod_h2 repository and tags, and Azure Linux’s pull request 20165. We downloaded the 2.4.71 source tarball from Apache and read the modules/http2 folder, and we ran the grep and ALPN checks above. We did not run Apache or any exploit and did not open any public proof of concept. Our only tests against live servers were TLS handshakes with sxz.io, httpd.apache.org and example.com, plus one header request to httpd.apache.org. Trackers and records change, so the tables show our readings at the times given. “Our reading” marks inferences that are ours.

• Reports: SecurityWeek, Wordfence, Wiz
• Apache: 2.4 vulnerabilities, oss-security post, CHANGES for 2.4.71, Protocols, mod_http2, httpd program options, stopping and restarting
• Records: CVE record, NVD, CISA KEV feed, FIRST EPSS
• Source: pull request 975, pull request 977, commit 824beab, h2_request.c at 2.4.71, mod_http2.c at 2.4.71
• Vendors: Red Hat CVE data, Debian DSA-6620-1, Debian tracker, Ubuntu tracker, SUSE, Amazon Linux, Gentoo, Azure Linux pull request 20165
• Earlier on sxz.io: Anthropic’s OSS Scanner launch, curl 8.23.0 and the Brotli flaw and its vendor ratings