Apache says 2.4.71 fixes critical mod_http2 RCE CVE-2026-119618, 16 days after Anthropic's OSS Scanner report

16 days from first report to fix, and the first critical on Apache's page since October 2021

On 12 November 2026 the Apache HTTP Server Project's page of 2.4 vulnerabilities lists 2.4.71, released 2026-11-11, as fixing three CVEs: one critical, one important, one low. The critical one, CVE-2026-119618, is a flaw in mod_http2 that Apache's description says "can lead to RCE". The page gives two report dates for it, 26 October 2026 (credit: Anthropic's OSS Scanner) and 3 November 2026 (credit: two researchers at Google Cloud Vulnerability Research), and dates both the fix commit and the 2.4.71 release 11 November. From the first report to the fix and release is 16 days, and from the second report 8 days (both derived from the page's dates).

Two more intervals, both derived from the same page. The affected range starts at 2.4.55, which the page dates to 2023-01-17: that release came 1,394 days before the fix. And this is the first release block on the page with a critical rating since 2.4.51, released 2021-10-07, which is 1,861 days earlier. The only other critical ratings on the page are in 2.4.50 and 2.4.51, both October 2021. The rating is the Apache security team's own, and the page says it "may well vary from platform to platform".

What these numbers do not establish. They do not show that anyone has attacked a server with this flaw: neither page says so. They do not show that a default installation is exposed: that is not stated. They do not show the flaw sat unnoticed for 1,394 days, because the first version in an affected range is where the page starts counting, not a statement of when the code was written or who looked at it. And they do not show that the two reports describe the same trigger. This briefing was written from the Apache page, the CVE record, NVD's record and the CISA catalogue, read between 06:57 and 06:58 UTC on 12 November 2026; the Apache page was identical on a second read. Anything that can change in the next hour is time stamped below.

What Apache's page and the CVE record print about CVE-2026-119618

The mechanism, as printed. Apache's description reads: "Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers() can lead to RCE." The page title adds "heap corruption", and the record lists one weakness, CWE-362. That is all either prints about how the flaw works: a synchronisation fault in a function called assign_headers(), in the HTTP/2 module. Neither says what a request must look like, whether a client needs any condition to be met, or what a successful attack gives.

Versions. Affected: Apache HTTP Server from 2.4.55 through 2.4.70, and "mod_h2 from GitHub" from 2.0.8 through 2.0.42, which is the separately distributed copy of the module. Fixed: the page's heading for the block is "Fixed in Apache HTTP Server 2.4.71", with "Update 2.4.71 released" on 2026-11-11 and a fix commit of the same date (the identifier is in Technical details). It prints no mod_h2 release that fixes the flaw, and, unlike several older entries, no sentence recommending an upgrade. 2.4.70 has no block of its own on the page, so the page gives no release date for it and no list of what it fixed.

A word, not a score. The CVE record's only severity entry is a "Textual description of severity" of "critical", added by Apache as the record's assigner. It holds no CVSS vector and no score. NVD's record, fetched at 06:58 UTC on 12 November, was in status "Received" with empty metrics, so no score came from there either. Anything that sorts findings by CVSS has nothing to sort on yet, and "critical" is a label to be taken on Apache's word.

Exploitation and the CISA catalogue. Neither the page nor the record says the flaw has been exploited or that a proof of concept exists. The saved Known Exploited Vulnerabilities catalogue, version 2026.11.10 released at 19:03 UTC on 10 November, lists none of the three CVEs. That is weak evidence: the catalogue predates the CVE record, published at 14:54 UTC on 11 November, so it could not have listed it. A second fetch at 06:58 UTC on 12 November returned the same version. The CVE Program's own container adds a link to a post on the oss-security mailing list; it was outside the pages read for this briefing and its content is not used.

Zoom

Two credits, and what the page says about an OSS Scanner

The page's acknowledgements for CVE-2026-119618 hold two finder lines. The first reads "Anthropic's OSS Scanner, as vulnerability ANT-2026-MAPKT6MZ"; the second names two researchers (not repeated here) "of the Google Cloud Vulnerability Research". The page records them as "Reported to security team (Anthropic)" on 2026-10-26 and "Reported to security team (Google)" on 2026-11-03, eight days apart. The CVE record carries the same two dates, with times of 12:00 and 15:50 UTC, and gives its own discovery field as "UNKNOWN".

What the page does not say about the first credit is most of what a reader would ask. It does not say what an OSS Scanner is, whether the Apache project enrolled in it, how the report reached the security team, or whether anyone checked it before sending. This site's earlier briefing on OSS Scanner, written on 9 October from Anthropic's own pages, records Anthropic's description of a free service for open source maintainers who opt in, with reports it calls "model-generated and sent without human review". That is Anthropic's account of the service, not Apache's account of this report, and the Apache page does not connect the two.

Nor does the page say the two reports are independent of each other, or that they describe the same trigger. It prints two dates and two names and no description of either report. The record's identifier format, ANT-2026-MAPKT6MZ, is given as Anthropic's own vulnerability number; where it is tracked is not stated, and no Anthropic page was read for this briefing. The Apache page states no selling interest of its own.

One comparison from reading the 2.4.67 to 2.4.71 blocks (derived): this is the only finder line on them that names a scanner. The 2.4.69 block credits "Calif.io in collaboration with Anthropic" on CVE-2026-93546, and the 2.4.68 block credits "Calif.IO in collaboration with OpenAI Codex" on CVE-2026-49975, each with the other finders' names. Whether credit wording of that kind says anything about how the flaws were found is not stated.

HTTP/2 flaws on Apache's page: five CVEs in four releases

Reading the page's release blocks from 2.4.67 to 2.4.71 for titles that name HTTP/2 or mod_http2 finds five CVEs in four of the listed releases (derived; 2.4.66 lists none, and 2.4.70 has no block). The table sets them out. It is a count of listings, and the page does not say the five share a cause.

The other two CVEs in 2.4.71

CVE-2026-106023, important: mod_md. The title is "mod_md NULL pointer dereference leads to child process crash", and the description adds "during HTTP request processing". It affects 2.4.30 through 2.4.70. It was reported on 2026-09-29 and fixed by a commit dated 2026-11-11, 43 days later (derived). Three finder lines are printed: a research institute "working with 360 TuLongFeng", one individual with no organisation, and one researcher at striga.ai. The printed impact is a crash of a child process, which is availability, not code execution. Which mod_md settings are exposed, whether a request needs any credential, and any workaround are not stated, and no CVSS score for this CVE was read.

CVE-2026-109163, low: mod_vhost_alias. The title is "mod_vhost_alias 1 byte stack buffer overwrite (after CVE-2026-63292)" and it affects only 2.4.69 and 2.4.70. It was reported on 2026-10-05 and fixed by a commit dated 2026-11-11, 37 days later (derived). Five finders are listed; the organisations printed are CloudLinux / TuxCare and SYZD Research. The page links it to CVE-2026-63292, a moderate flaw in the same module fixed in 2.4.69 (released 2026-10-01, reported 2026-06-17), whose entry spells out its conditions: a Host header over 8192 bytes, VirtualDocumentRoot with a hostname format specifier, and LimitRequestFieldSize raised above the default. The new entry spells out no conditions, and the page does not say whether it is a regression or an incomplete fix. That its range is exactly the two releases from 2.4.69 on is the page's own range, not an explanation (derived reading).

Zoom

What the sources state, and what they do not

What to do, in order

The first item is Apache's. The rest is this site's suggestion, built from what the page leaves unsaid; none of it comes from Apache.

Technical details

Apache's page and the CVE record print no request, payload, configuration setting, log line, hash or network indicator for this flaw, and none is included here. What they print is identifiers, ranges, dates and commit ids. Each block below is attributed in its caption and copied from the saved page; where this site changed the layout or left a name out, the text above the block says so.

Apache's block for CVE-2026-119618. This is the entry on Apache's page, which is what to match against an inventory. The page lays the dated rows out as label and value in two columns; this site put a colon between them, and replaced the two Google researchers' names with a bracketed note. A defender uses the ranges and the fixed release.

Fixed in Apache HTTP Server 2.4.71
Released 2026-11-11 · 3 CVEs: 1 critical, 1 important, 1 low
CVE-2026-119618 (critical): mod_http2: heap corruption and RCE in assign_headers
Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers() can lead to RCE.
This issue affects Apache HTTP Server: from 2.4.55 through 2.4.70.
Affected releases of mod_h2 from GitHub: from 2.0.8 through 2.0.42.
Acknowledgements:
finder: Anthropic's OSS Scanner, as vulnerability ANT-2026-MAPKT6MZ
finder: [two researcher names left out by this site] of the Google Cloud Vulnerability Research
Reported to security team (Anthropic): 2026-10-26
Reported to security team (Google): 2026-11-03
fixed in 2.4.x by 824beab9b9424d6cfb29595248fdbf6c3dddeab1: 2026-11-11
Update 2.4.71 released: 2026-11-11
Affects: 2.4.55 through 2.4.70

The CVE record. These are selected fields of the CVE Program record, one per line, with the values as stored. The record holds Apache's textual severity only. A defender uses the version range and the CWE to tag the finding in a tracker, and the dates to time stamp it.

cveId: CVE-2026-119618
state: PUBLISHED
assignerShortName: apache
dateReserved: 2026-10-30T12:32:13.904Z
datePublished: 2026-11-11T14:54:08.155Z
dateUpdated: 2026-11-11T19:05:06.932Z
title: Apache HTTP Server: mod_http2: heap corruption and RCE in assign_headers
problemTypes: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization
affected: Apache Software Foundation, Apache HTTP Server, version 2.4.55, lessThanOrEqual 2.4.70, versionType semver, defaultStatus unaffected
metrics: Textual description of severity: critical (scenario GENERAL)
timeline: 2026-10-26T12:00:00.000Z reported (Anthropic)
timeline: 2026-11-03T15:50:00.000Z reported (Google)
credits: Anthropic's OSS Scanner, as vulnerability ANT-2026-MAPKT6MZ (type finder)
source: discovery UNKNOWN

The fix commits. The page names a commit for each of the three CVEs in 2.4.71, all dated 2026-11-11. A distribution advisory or a changelog that cites one of these commits shows the fix has been taken into that package, whatever its version number says. The page does not link the commits and none was read.

CVE-2026-119618 (critical)   fixed in 2.4.x by 824beab9b9424d6cfb29595248fdbf6c3dddeab1   2026-11-11
CVE-2026-106023 (important)  fixed in 2.4.x by 1b47e95c61fb9cf9b864f352c1d3bef7a2467606   2026-11-11
CVE-2026-109163 (low)        fixed in 2.4.x by 5566851a064993eec4b2c6cb185882f627501aa6   2026-11-11

NVD's record at 06:58 UTC on 12 November. NVD had received the record but not analysed it: no metrics, and the weakness entry came from Apache as a secondary source. If a scanner or ticket system shows no score for this CVE today, this is why.

id: CVE-2026-119618
sourceIdentifier: security@apache.org
published: 2026-11-11T15:17:15.900
lastModified: 2026-11-11T19:17:30.313
vulnStatus: Received
metrics: (empty)
weaknesses: security@apache.org, type Secondary, CWE-362
affected: security@apache.org, Apache HTTP Server, version 2.4.55, lessThanOrEqual 2.4.70, semver
(response timestamp 2026-11-12T06:58:21.784)

The question the page leaves open

Apache has said which versions are affected, which release fixes the flaw, and how quickly it moved: 16 days from the first report, 8 from the second. It has not said which of your servers are actually reachable, and neither has any page read for this briefing. Of your Apache servers from 2.4.55 to 2.4.70, which ones speak HTTP/2 today, and is the version written in your asset record the version that is running?

Key facts