AI scanner found a critical Apache HTTP/2 flaw — update to 2.4.71 or switch HTTP/2 off

The Apache Software Foundation released Apache HTTP Server 2.4.71 on November 11, 2026, fixing a critical flaw in its HTTP/2 module (CVE-2026-119618) that can lead to remote code execution. It was first reported by Anthropic's AI-driven OSS Scanner and, independently, by Google researchers. If you run Apache 2.4.55 through 2.4.70 with HTTP/2 enabled, install 2.4.71 or your distribution's patched package now. If you can't yet, turn HTTP/2 off as a stopgap.

What happened, in plain English

Apache HTTP Server ("httpd") is one of the most widely used web servers. It sits behind company websites, intranets, WordPress sites, admin portals and plenty of internal tools. Modern browsers talk to it using HTTP/2, a faster version of the web's basic protocol that lets many requests share one connection. In Apache, a component called mod_http2 handles that.

The bug is a race condition: two parts of the server, running at the same time in different threads, touch the same piece of memory without coordinating. Think of two clerks writing on the same form at once — the result can be garbage. Here, the "garbage" is corrupted server memory. Red Hat says this could let a remote attacker, with no password, run their own commands on the server. Red Hat scores it 9.8 out of 10 on the Common Vulnerability Scoring System (CVSS). Apache rates it critical.

What makes this story unusual is who found it. According to Apache's advisory, the first report, on October 26, 2026, came from Anthropic's OSS Scanner. That's a free, opt-in service launched in October that points Anthropic's AI models at open-source projects. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported the same bug on November 3. Apache shipped the fix 16 days after the first report.

As of November 12, Wiz, Horizon3.ai and SecurityWeek all reported no known attacks using this flaw.

Are you affected? What to do now

Who is affected: servers running Apache HTTP Server 2.4.55 through 2.4.70 that actually serve HTTP/2. That includes "h2" over TLS and "h2c" in clear text. Apache also lists the standalone mod_h2 module from GitHub, versions 2.0.8 through 2.0.42. According to Red Hat, servers that only speak HTTP/1.1 are not vulnerable. RHEL 8 and older are not affected. RHEL 9 and 10 are affected, but Red Hat rates them "Important" rather than critical because of how memory is allocated there.

If your sites run on a managed host, a content delivery network or a platform as a service (PaaS), ask the provider. You can't patch someone else's web server, and as Wordfence pointed out (via SecurityWeek), a WordPress update won't fix it either.

Checklist, in order:

• Inventory. Find every Apache instance: physical and virtual servers, containers, appliances, and reverse proxies in front of other apps. Wiz data showed 64% of cloud environments contained affected Apache versions, and 51% had publicly exposed ones. Wiz notes those numbers ignore configuration, so many may not be exploitable.
• Check whether HTTP/2 is on. Confirm that mod_http2 is loaded and that a Protocols directive (server-wide or in any virtual host) lists h2 or h2c. Testing from outside that a client can negotiate h2 is the surest check.
• Patch. Upgrade to 2.4.71, or install your vendor's fixed package. Distributions often backport fixes without changing the version string to 2.4.71, so go by the vendor's advisory or changelog, not the version number. Status as of November 13:
  • Debian: fixed for trixie (DSA-6620-1, package 2.4.71-1deb13u1) and for bookworm (LTS advisory DLA-4902-1, 2.4.71-1deb12u1), per the Debian security tracker.
  • Red Hat Enterprise Linux (RHEL) 9 and 10: affected. Check the Red Hat CVE page for errata.
  • Ubuntu: As of November 12, secondary reports said Ubuntu had published no security notice yet. Ubuntu 24.04 and 26.04 ship Apache versions in the affected range. Watch Ubuntu's CVE tracker. We could not confirm Ubuntu's status directly.
• Stopgap if you can't patch today. Restrict the server to Protocols http/1.1, set server-wide and in every virtual host that overrides it, then restart. This is the workaround Wiz and Horizon3 describe. Before you do it, check whether anything depends on HTTP/2, such as gRPC back ends or HTTP/2-only clients.
• Containers. Rebuild and redeploy images. An image pinned to an old base stays vulnerable even after the host is patched.
• Front-end devices. If a load balancer, web application firewall (WAF) or reverse proxy sits in front of Apache, check whether it passes HTTP/2 through to Apache or downgrades it to HTTP/1.1. Pass-through keeps Apache exposed.
• Watch. No official indicators of compromise have been published. Unexpected Apache worker crashes or restarts after the disclosure are worth a look, since the public proof of concept causes crashes.

The expert view

The mechanism. HTTP/2 multiplexes many streams over one connection. mod_http2 therefore juggles per-stream state across worker threads. Apache's description names assign_headers() and calls the bug "concurrent execution using shared resource with improper synchronization." Red Hat explains it more concretely: one thread can write into memory owned by another, which corrupts the heap. In C, heap corruption that an attacker can trigger remotely is the classic starting point for code execution. Turning it into a working exploit depends on allocator behaviour and threading: Red Hat's per-stream allocator note is the reason it downgrades RHEL 9 and 10 to Important. That's why mitigation advice centres on whether h2 is actually negotiated, not just whether the module is installed.

Exploit status is murky. Read it carefully. Red Hat's page says "public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled," but it doesn't say whose research. The Cloud Security Alliance and Horizon3.ai both say they could not find it. A public proof of concept on GitHub, published November 12, reproduces memory corruption and crashes but does not show code execution. The cautious reading: treat code execution as realistic and patch on an emergency timeline, but there is no confirmed in-the-wild exploitation.

What's genuinely new. AI-assisted bug finding isn't new. What's new is an AI system as the first named finder of a critical, pre-authentication bug in core internet infrastructure, reached through a mass, automated service. Anthropic says OSS Scanner output is "fully model-generated, without human review or triage." It also says that in its earlier validation, 85 of 97 critical and high-severity findings across 48 projects met its disclosure bar. In this case the report held up: a human team at Google found the same bug eight days later, and Apache shipped a fix.

Why it matters beyond Apache. This fits a pattern we've tracked this month: Fortinet crediting AI-assisted testing for a batch of critical firewall fixes, and Forescout's November 12 report of 66 new bugs in embedded TCP/IP stacks found with an AI harness. Discovery is getting cheaper and faster, so the bottleneck shifts to defenders: maintainers triaging reports, distributions backporting fixes, and admins rolling them out. The Debian picture on day two shows the problem: one stable release had a security advisory, another relied on the LTS team, and the testing branch was still listed as vulnerable. Attackers can read upstream diffs too.

Still unknown: whose "reliable exploit" Red Hat refers to; Ubuntu's fix timeline; a fixed standalone mod_h2 release (sources disagree); and whether the companion fixes in 2.4.71 interact with any workaround. Those are CVE-2026-106023, a mod_md crash rated important, and CVE-2026-109163, a low-severity mod_vhost_alias overflow.

Official sources

• Apache HTTP Server 2.4 vulnerabilities — 2.4.71 release (Apache Software Foundation)
• CVE-2026-119618 (Red Hat)
• CVE-2026-119618 (Debian security tracker)
• Launching an opt-in vulnerability-finding service for open source (Anthropic)
• Wiz: Critical RCE vulnerability in Apache HTTP Server
• Horizon3.ai: CVE-2026-119618
• Coverage: SecurityWeek
• Coverage: Cloud Security Alliance research note
• Coverage: BleepingComputer