Apache's HTTP/2 Bug Can Hand Attackers Your Server. Patched Yet?

The Apache HTTP Server Project shipped httpd 2.4.71 on November 11, 2026 to fix CVE-2026-119618, a critical race condition in its HTTP/2 module that Apache says "can lead to RCE" on versions 2.4.55 through 2.4.70. A public proof of concept that reproduces the heap corruption landed on GitHub a day later. If your Apache server speaks HTTP/2, this is this weekend's patch.

Here's what you need to know:

• Affected: Apache httpd 2.4.55 to 2.4.70 and the standalone mod_h2 module 2.0.8 to 2.0.42. The fix is in httpd 2.4.71.

• Only HTTP/2 is exposed. The bug sits in mod_http2, so servers that serve only HTTP/1.1 aren't reachable through it. Apache's default Protocols setting is http/1.1.

• No login needed. An unauthenticated attacker can trigger it with crafted HTTP/2 requests, over TLS (h2) or cleartext (h2c).

• Two teams found it independently: Anthropic's OSS Scanner on October 26 and Google Cloud Vulnerability Research on November 3.

• No confirmed attacks yet, and the public PoC shows heap corruption, not working code execution. That gap tends to close fast.

How one HTTP/2 request shape corrupts Apache's heap

What Happened

The Apache HTTP Server 2.4 security advisory lists three fixes in 2.4.71, released November 11: one critical, one important and one low. The critical one is CVE-2026-119618, titled "mod_http2: heap corruption and RCE in assign_headers". Apache describes it as a "Concurrent Execution using Shared Resource with Improper Synchronization vulnerability", which is CWE-362, a race condition.

The advisory credits two finders. Anthropic's OSS Scanner reported it on October 26 as ANT-2026-MAPKT6MZ, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it on November 3. The fix landed in the 2.4.x branch as commit 824beab.

So what actually breaks? According to the Sysdig Threat Research Team's analysis, the trigger is a body-less HTTP/2 request that carries a Content-Type header but no Content-Length. For that request, a worker thread wrote a synthesised Content-Length: 0 header into a table owned by the connection, instead of the per-request table. Red Hat, quoted by Sysdig, sums up the root cause as "a worker thread writes into memory owned by the connection thread through a shared, lock-free allocator." Two threads, one heap, no lock. The fix is a one-line change that writes the header into the right table.

The timeline moved quickly. Sysdig records public disclosure on oss-security at 12:19 UTC on November 11, Red Hat's assessment and RHEL fixes 33 minutes later, and the CVE record that afternoon. On November 12, a public proof of concept on GitHub reproduced the bug in a lab build of httpd 2.4.70: 6,080 requests produced five AddressSanitizer crash reports and 31 ThreadSanitizer allocator races naming assign_headers(). The same traffic against 2.4.71 came back clean. The PoC's own README lists the impact as "heap corruption in an httpd child process; potential remote code execution". It doesn't demonstrate code execution.

Severity scores don't agree, and that's worth knowing before your scanner pings you. Apache rates the flaw critical but, as Sysdig notes, the CVE record carries no CVSS score. Red Hat and Amazon score it 9.8 on CVSS v3.1, while CISA's score is 8.1. Red Hat rates its own RHEL 9 and 10 builds "Important" because they allocate each HTTP/2 stream from a separate allocator, which makes exploitation much harder. RHEL 6, 7 and 8 aren't affected.

How many servers are in the blast radius? BleepingComputer reports that, according to Wiz telemetry, 64% of cloud environments contain vulnerable resources and roughly half of those have publicly exposed instances. Those numbers don't account for configuration, though, since HTTP/2 has to be switched on. BleepingComputer also quotes watchTowr's advice: "patch now or drop h2 until you can."

Why It Matters

Apache httpd isn't the shiny part of anyone's stack, which is exactly why this bug matters. It quietly fronts WordPress sites, PHP apps, internal tools, reverse proxies and plenty of legacy services that nobody has touched in years. BleepingComputer estimates it backs roughly one in five websites.

The bug also lives in the server itself, not in your application code. Clean code, a careful framework and a strong WAF rule set don't help if the parser of the connection is the thing that's broken. A successful exploit, as Wiz explains, would run commands with the privileges of the web server process. That's usually enough to read app secrets, database credentials and anything else the www-data or apache user can see.

There's a second, sneakier lesson. Sysdig points out that servers upgraded to 2.4.67 in May for an earlier HTTP/2 flaw, CVE-2026-23918, are still inside this CVE's affected range. Patching once doesn't mean you're done with a module. If HTTP/2 is turned on, mod_http2 is now one of the most security-sensitive pieces of your web tier.

And the way this bug was found says something about where security research is going. One of the two finders was an automated, model-driven scanner from Anthropic, which beat a human research team by eight days. We've covered that trend before in Anthropic's Claude exploit-chain research on Chrome, Safari and Linux. When machines can find memory-safety bugs in mature C code this quickly, the window between "bug exists" and "someone weaponises it" gets shorter for defenders too.

What It Means for Developers

Start by working out whether you're exposed, then patch. Here's the short list:

• Check your version. Run httpd -v or apache2 -v. Anything from 2.4.55 to 2.4.70 is in range. But distributions often backport fixes without bumping the upstream number, so check your vendor's advisory too, not just the version string.

• Check whether HTTP/2 is on. Look for h2 or h2c in every Protocols line, server-wide and inside each virtual host, and confirm the module is loaded:

# Is mod_http2 loaded?
apachectl -M 2>/dev/null | grep -i http2

# Is HTTP/2 enabled anywhere (server-wide or per vhost)?
grep -RniE '^\s*Protocols\s' /etc/apache2 /etc/httpd 2>/dev/null

# What does the server actually negotiate? ("2" means HTTP/2)
curl -s -o /dev/null -w '%{http_version}\n' --http2 https://your-site.example/

• Patch to 2.4.71 or your distro's fixed package. Sysdig says fixes were out as of November 13 for Debian 12 and 13, Ubuntu 22.04 through 26.10, Alpine, Fedora, Amazon Linux 2 and 2023, Wolfi and Chainguard, plus RHEL 9 and 10. SUSE, openSUSE, Photon OS and several RHEL rebuilds were still waiting.

• Can't patch today? Drop HTTP/2. Wiz recommends setting Protocols http/1.1 and restarting Apache. Note that's Wiz's guidance, not Apache's, but it matches Red Hat's statement that HTTP/1.1-only servers aren't affected. You'll lose HTTP/2 multiplexing until you upgrade, which is a fair trade.

• Rebuild your containers. If your Dockerfile starts from an httpd or distro base image, pull a fixed base, rebuild and redeploy. Running containers don't patch themselves.

• Hunt for standalone mod_h2. Sysdig notes the standalone mod_h2 repository has been archived since June 9, 2026, so there's no new release in that line. Move to the module bundled with httpd 2.4.71.

• Watch for crashes. Repeated child-process crashes or segfaults in Apache's error log on HTTP/2 traffic deserve a closer look. In the public PoC's lab, the vulnerable build crashed with segfaults under this traffic.

If you're running a big patch weekend anyway, our PostgreSQL 52-CVE patch-day guide and the Next.js and React critical RCE patch guide cover two other layers of the same stack.

Am I exposed? Your Apache HTTP/2 patch plan

What's Next

The big open question is whether anyone turns the heap corruption into reliable code execution. Sysdig says Red Hat's CVE page mentions public research showing "a reliable exploit against a default-configured server", but with no researcher named or details linked, Sysdig couldn't verify it. As of Sysdig's post, there's no confirmed in-the-wild exploitation and the CVE isn't in CISA's Known Exploited Vulnerabilities catalog.

Watch three things this week. First, whether a working RCE exploit goes public, which would push this to the top of every incident-response queue. Second, whether CISA adds it to KEV, which sets patch deadlines for US federal agencies and often nudges everyone else. Third, fixes for the remaining distributions, plus downstream products like Red Hat JBoss Core Services that repackage httpd.

Apache hasn't published a workaround in its advisory, and the CVE record still has no official CVSS score. Expect scanners and dashboards to show conflicting severities until that settles.

FAQ

Is my Apache server vulnerable to CVE-2026-119618?

Only if it runs httpd 2.4.55 to 2.4.70 (or standalone mod_h2 2.0.8 to 2.0.42) and has HTTP/2 enabled through h2 or h2c in a Protocols directive. Distro packages may carry backported fixes, so check your vendor's advisory as well as the version number.

Is there a public exploit for the Apache HTTP/2 bug?

A public proof of concept reproduces the heap corruption in a lab, but it doesn't demonstrate code execution. No in-the-wild attacks had been confirmed as of November 13.

What's the quickest fix if I can't upgrade right now?

Remove h2 and h2c from your Protocols directives so it reads Protocols http/1.1, then restart Apache. That's a temporary step recommended by Wiz; upgrading to 2.4.71 is the real fix.

Want the next "patch this now" alert before it hits production? Subscribe to the free TheTechLane newsletter for developer-focused security news, patch checklists and tutorials, straight to your inbox.

Sources

• Apache HTTP Server 2.4 vulnerabilities (fixed in 2.4.71), The Apache HTTP Server Project

• Apache httpd 2.4.71 release announcement, The Apache HTTP Server Project

• mod_http2 documentation and Protocols directive, Apache HTTP Server docs

• CVE-2026-119618 detail, NIST National Vulnerability Database

• CVE-2026-119618 security page, Red Hat

• GHSA-hjhf-gpg9-qqfj advisory, GitHub Advisory Database

• Detecting heap corruption and RCE in Apache HTTP Server mod_http2, Sysdig Threat Research Team

• Critical RCE vulnerability in Apache HTTP Server: everything you need to know, Wiz

• Apache HTTP Server patches critical HTTP/2 remote code execution flaw, BleepingComputer

• CVE-2026-119618 proof-of-concept lab, GitHub (googlesky)

Follow TheTechLane

Keep learning AI, development, and modern developer technologies with TheTechLane.

Learn • Build • Share

Follow @thetechlanehq for more developer guides, tutorials, and practical technology content.