CVE-2026-119618: Apache HTTP/2 RCE Flaw Fixed in 2.4.71—Check Exposure and Patches

What happened​

The Apache HTTP Server Project released version 2.4.71 on 11 November 2026. Its 2.4 vulnerabilities page lists CVE-2026-119618 as fixed in that release and rates it critical. BleepingComputer reported that an unauthenticated attacker could exploit the flaw to get remote code execution. The weakness is a thread-safety flaw in mod_http2 that lets an unauthenticated HTTP/2 client corrupt memory and possibly run code.

Apache's own wording is dry. It calls this a concurrent-execution problem involving a shared resource with improper synchronization, in the assign_headers() function, that "can lead to RCE". In plain terms, it is a race condition. Two threads touch the same memory without proper coordination, and the heap gets corrupted.

Who found it: Apache credits Anthropic's OSS Scanner (identifier ANT-2026-MAPKT6MZ) and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research. Red Hat's advisory also thanks Weems and Scannell.

Affected versions​

• Apache HTTP Server 2.4.55 through 2.4.70, inclusive.
• Standalone mod_h2 releases 2.0.8 through 2.0.42, according to BleepingComputer and other reports.
• The fix is in Apache HTTP Server 2.4.71.

The affected range starts at httpd 2.4.55, released in January 2023, which brought in the mod_http2 2.0.x code line. Red Hat says mod_http2 versions before 2.0.8 do not contain the affected code.

The HTTP/2 condition​

The flaw only matters if HTTP/2 is actually in play. Red Hat says the exposure applies to servers with h2 or h2c enabled through the Protocols directive. It says servers serving only HTTP/1.1 are not affected. Other write-ups describe the same condition. A server is exposed only when httpd is 2.4.55 through 2.4.70, mod_http2 is loaded, and a Protocols line offers h2 or h2c.

BleepingComputer says HTTP/2 is off by default. I would treat that with caution. Apache's own advisory language on this page does not settle defaults across distributions and packaged builds. One distribution-focused write-up from ComputingForGeeks lists HTTP/2 as not on by default for Ubuntu's archive builds. Your configuration management, container image or hosting panel may have switched it on years ago, so check the effective configuration instead of assuming.

How the bug works​

Red Hat describes the root cause as a worker thread writing into memory owned by the connection thread through a shared, lock-free allocator. HTTP/2 lets clients send many requests at once over one connection, and mod_http2 handles them with multiple threads.

The upstream fix is tiny. The commit changes one line in modules/http2/h2_request.c. When a request has a content type but the stream has already ended, the code sets Content-Length to 0. It used to write that into req->headers. It now writes into r->headers_in. The small change points to shared request-header state as the problem. Security firm Threat Landscape describes the old code as cloning a shared header table and then writing to the shared copy, though I could not verify that independently of its blog.

How bad is it, and is it being exploited?​

The sources disagree on severity and exploitation, so keep these distinctions in mind.

• Apache rates it critical.
• Red Hat scores it CVSS 9.8 (network, low complexity, no privileges, no user interaction). It still rates RHEL 9 and RHEL 10 as Important rather than Critical. Those builds allocate each HTTP/2 stream from a separate allocator, which Red Hat says substantially increases exploitation complexity. RHEL 8 and earlier are not affected.
• Wiz, as quoted by BleepingComputer, calls it critical but says no official score exists. Wiz said it knew of no public exploits or attacks at the time. Wiz telemetry cited in the report says 64% of cloud environments have vulnerable resources, and roughly half of those have publicly exposed instances. That figure does not account for whether HTTP/2 is enabled, so it is not a count of exploitable servers.
• Red Hat says public research has demonstrated a reliable exploit against a default-configured server with mod_http2 enabled. That sits awkwardly with Wiz's "no public exploits" statement. The two may reflect different evidence thresholds or timing. Don't assume it is safe to wait. Apache's own notice does not establish in-the-wild exploitation.

Distribution patches: the "2.4.71" trap​

Distributions often backport fixes into older version numbers, so a version string can mislead you in both directions.

• Red Hat lists fixes for RHEL 9 and RHEL 10 dated 11 November 2026. ComputingForGeeks lists them as mod_http2 2.0.29-5.el10_3.1 and 2.0.26-7.el9_9.1.
• ComputingForGeeks reports Debian 13 fixed via DSA-6620-1 with apache2 2.4.71-1~deb13u1.
• The Cloud Security Alliance notes that Debian's tracker lists a bookworm-security package at 2.4.71-1~deb12u1 that it still marks vulnerable. It advises Debian 12 operators to confirm status directly rather than trust the version string.
• ComputingForGeeks showed Ubuntu 22.04, 24.04 and 26.04 archive packages with no security notice yet. Check again, because that was a snapshot.

A scanner that only reads version strings may flag a fixed backport as vulnerable, as Red Hat itself warns. A scanner may also pass a build that merely carries a "2.4.71" label.

What to do​

1. Inventory. Find every Apache HTTP Server instance, including appliances, containers, dev boxes and Windows builds. Note the version and whether mod_http2 is loaded.
2. Check the config. Look for Protocols lines offering h2 or h2c. Inspect virtual hosts as well as the global config.
3. Patch. Upgrade upstream builds to 2.4.71 or later. For distribution packages, install the vendor's fixed package and read the advisory for your exact release. Restart httpd afterward.
4. If you can't patch yet, switch off HTTP/2 only if your service can live without it. Restricting to HTTP/1.1 removes the exposed protocol path, per Red Hat. Test first. Apache's page lists no workaround, and some write-ups say as much, so treat this as risk reduction rather than a fix. It also does not replace the update.
5. Verify afterward. Confirm the running version or package changelog, and check that your HTTP/2 clients still negotiate as expected.

Two other fixes in 2.4.71​

The release fixes three vulnerabilities in total: one critical, one important and one low.

• CVE-2026-106023 is a null pointer dereference in mod_md during HTTP request processing. It affects 2.4.30 through 2.4.70 and can crash a child process. Apache rates it important. BleepingComputer's report did not give a rating for it, so go by Apache's rating.
• CVE-2026-109163 is a one-byte stack buffer overwrite in mod_vhost_alias. It affects 2.4.69 and 2.4.70, and Apache rates it low. Apache describes it as a follow-up to CVE-2026-63292.

These two reach well beyond HTTP/2 servers, so they give you reason to update even if you never enable h2.

Why Windows admins should care​

Apache is not a Microsoft product, but it is a common reverse proxy and front end in mixed environments. It sits in front of web apps, intranet portals and application stacks that many Windows shops run. This is a pre-authentication flaw in a network-facing service that, per Red Hat, can run commands with the web server process's privileges. That is the kind of foothold attackers like for lateral movement. Check your Apache servers even if your fleet is mostly Windows. Treat the patch as a standard emergency change, then retest HTTP/2 performance once it lands.

One footnote on discovery: an AI-assisted scanner found this bug, and a human research team found it separately. Expect more advisories to arrive this way, and expect your patch windows to get tighter.