Apache httpd 2.4.71 fixes a critical mod_http2 race that leads to RCE: CVE-2026-119618

The Apache HTTP Server Project released httpd 2.4.71 on November 11, 2026, and recommends it over every earlier release. The release fixes three CVEs. One of them, CVE-2026-119618, carries a critical rating: a race condition in mod_http2 that the security team says "can lead to RCE."

If you serve HTTP/2 from Apache 2.4.55 or later, you are in range.

CVE-2026-119618

The Apache advisory describes improper synchronization around a shared resource in assign_headers() inside mod_http2, and its title names heap corruption as the path to code execution. Two groups found it on their own:

1. 2026-10-26

   Anthropic's OSS Scanner reports the bug to the Apache security team as ANT-2026-MAPKT6MZ.

2. 2026-11-03

   Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research report the same bug.

3. 2026-11-11

   The team commits the fix to the 2.4.x branch and releases 2.4.71.

Sixteen days passed between the first report and the release. The advisory doesn't publish a proof of concept or attack details, and it lists no workaround.

Watch the second row. If you built the standalone mod_h2 module from GitHub to get a newer HTTP/2 stack, upgrading the httpd package won't replace your module. Check which .so file your config loads.

The other two CVEs

The mod_md bug matters if you let Apache manage your ACME certificates. Researchers at 360 Vulnerability Research Institute reported it on September 29, along with Lucian Nitescu and Bartlomiej Dmitruk of striga.ai. An attacker can crash child processes during request processing.

The advisory files the mod_vhost_alias bug as a follow-up to CVE-2026-63292, a stack overflow through oversized Host headers that 2.4.69 fixed on October 1. The new one-byte overwrite affects 2.4.69 and 2.4.70 alone.

Check your servers

# version
httpd -v            # or apache2 -v on Debian and Ubuntu

# is mod_http2 loaded?
apachectl -M 2>/dev/null | grep -E 'http2|h2'

# which Protocols does each vhost offer?
grep -RniE '^\s*Protocols' /etc/httpd /etc/apache2 2>/dev/null

If http2_module shows up and the version sits between 2.4.55 and 2.4.70, you need the update. If you can't patch today, you can stop offering HTTP/2 so clients never reach the vulnerable code:

# before
Protocols h2 h2c http/1.1

# after, until 2.4.71 is installed
Protocols http/1.1

Commenting out the LoadModule http2_module line does the same job. Your clients lose HTTP/2 multiplexing until you switch it back on, so run apachectl configtest, reload, and plan to revert after the upgrade.

Other changes in 2.4.71

The CHANGES file lists a handful of fixes worth reading before you roll out:

• mod_md accepts MDHttpProxy and MDCACertificateFile per MDomain, and a new MDHttpProxyCACertificateFile directive sets the CA certificates for an HTTPS proxy.
• mod_remoteip now applies RemoteIPTrustedProxyList and RemoteIPInternalProxyList per virtual host and merges entries from the main server, logging a warning when both define some. Recheck client IPs in your logs after the upgrade if you set these lists in two places.
• mod_http2 accepts the asterisk form of OPTIONS requests, and no longer crashes with H2PushDiarySize 0 and debug logging on.
• mod_dav handles an invalid or overflowing Timeout: header by granting the RFC 4918 maximum, where it used to grant a lock that had already expired.

This week

1. Inventory every Apache instance, including the ones inside container images and appliance VMs, and record the version and whether http2_module loads.
2. Upgrade to 2.4.71 or your distribution's patched package, and restart httpd. Rebuild images that bake Apache in.
3. If you build mod_h2 from GitHub, rebuild it from a release newer than 2.0.42.
4. Where you can't patch yet, drop h2 and h2c from Protocols and reload.