Apache HTTP Server 2.4.71 fixes a critical HTTP/2 flaw that can let attackers run code. Patch or turn off h2.

The Apache Software Foundation released httpd 2.4.71 on November 11 to fix CVE-2026-119618, a race condition in mod_http2 that can corrupt memory and lead to remote code execution. Versions 2.4.55 through 2.4.70 with HTTP/2 turned on are exposed. Wiz says 51% of cloud environments it scans have a publicly exposed affected instance.

If you run Apache HTTP Server 2.4.55 through 2.4.70 with HTTP/2 turned on, update to 2.4.71 today. If you can’t, take h2 and h2c out of your Protocols line so the server speaks only HTTP/1.1 until you can. The Apache Software Foundation rates the bug, CVE-2026-119618, critical: an attacker who needs no login can corrupt memory in the HTTP/2 module and run code with the web server’s privileges.

What Apache fixed

Apache released httpd 2.4.71 on Wednesday, November 11, with three security fixes, one rated critical. The critical one is a race condition in assign_headers() inside mod_http2, the module that handles HTTP/2. When threads share a resource without proper locking, an attacker can corrupt heap memory, and Apache says that can lead to remote code execution.

• Affected: Apache HTTP Server 2.4.55 through 2.4.70, and the standalone mod_h2 module from GitHub, versions 2.0.8 through 2.0.42.
• Fixed: httpd 2.4.71. For standalone mod_h2, Wiz says to move to a release newer than 2.0.42.
• Found by: Anthropic’s OSS Scanner, which reported it to Apache on October 26, and Anthony Weems and Simon Scannell of Google Cloud’s Vulnerability Research team, who reported it independently on November 3.

The same release fixes CVE-2026-106023, rated important, a NULL pointer bug in mod_md that crashes a child process (2.4.30 through 2.4.70), and CVE-2026-109163, rated low, a one-byte stack overwrite in mod_vhost_alias (2.4.69 and 2.4.70).

Who is exposed

Only servers with HTTP/2 enabled are at risk. HTTP/2 is off in a default Apache setup, BleepingComputer notes. Check your own configuration rather than assuming the default.

Cloud security company Wiz says 64% of the cloud environments it scans contain a resource running an affected version, and 51% have a publicly exposed one. Wiz says those figures don’t account for whether HTTP/2 is turned on. As of its post, Wiz knew of no public exploit and no attacks. Researchers at watchTowr confirmed the HTTP/2 condition, according to BleepingComputer, and told admins to “patch now or drop h2 until you can.”

What to do

• Find your version. Run httpd -v or apache2 -v on each server, including the ones inside Docker images and reverse proxies you forgot about.
• Check for HTTP/2. Look for h2 or h2c in the Protocols directive and for mod_http2 in your loaded modules (apachectl -M). No HTTP/2 means this bug can’t be reached, though you still want 2.4.71 for the other two fixes.
• Update. Install 2.4.71 from source or your vendor. If your Linux distribution backports fixes into an older version number, wait for its advisory and confirm it names CVE-2026-119618.
• If you can’t update today, set Protocols http/1.1 in httpd.conf, as Wiz recommends, and restart Apache. Browsers fall back to HTTP/1.1 on their own.
• Rebuild images. A container built on an affected base image stays vulnerable until you rebuild and redeploy it.

One web server in five is a big patch queue

This is our analysis. Apache still runs roughly one in five websites, according to W3Techs figures cited by BleepingComputer, and much of that is the forgotten kind: a marketing site on a VPS, a staging box, a vendor appliance. A critical flaw with no exploit yet is the cheapest moment to patch. An AI scanner found this one first, and the fix landed days after OpenAI said GPT-6 Cyber found hundreds of Linux kernel flaws. Expect critical server fixes to arrive faster, and keep a list of every server you would need to patch in an afternoon. If your Ubuntu or Debian hosts also missed this month’s APT fix or the kernel TCP patch, do them in the same maintenance window.