Apache HTTP Server mod_http2 Remote Code Execution (CVE-2026-119618)

CVE-2026-119618 is a race condition in assign_headers(), part of the Apache HTTP Server's HTTP/2 module (mod_http2). It corrupts heap memory and can lead to remote code execution (RCE) by an unauthenticated attacker. Apache HTTP Server 2.4.55 to 2.4.70 is affected when HTTP/2 is enabled.

Apache rates the vulnerability critical, and Red Hat scores it 9.8 under CVSS 3.1. The fix was released in Apache HTTP Server 2.4.71 on 11 November 2026.

Upgrade to Apache HTTP Server 2.4.71, or apply your distribution's patched package. Start with internet-facing servers that have HTTP/2 enabled. If your distribution has not released a fix yet, you can disable HTTP/2 as a stop-gap until it does.

Exploitation status

Red Hat states that public research has demonstrated a reliable exploit against a server with HTTP/2 enabled and otherwise default settings. As of 12 November 2026, we have found no confirmed reports of exploitation in the wild.

Third-party repositories claiming to scan for or exploit the issue have started to appear. With a working exploit already demonstrated, treat patching as urgent. We are not linking to them.

Root cause

Apache describes the vulnerability as concurrent execution using a shared resource with improper synchronisation. In Red Hat's technical explanation, HTTP/2 stream workers and the connection thread share an allocator that is not thread-safe. A worker thread can therefore write into memory owned by the connection thread, resulting in heap corruption. The fix was committed to the 2.4.x branch (commit 824beab) and released in 2.4.71 on 11 November 2026.

Who is affected

Affected servers are those offering Apache configured with h2 (HTTP/2 over TLS) or h2c (HTTP/2 over cleartext) through the Protocols directive. A server that only supports HTTP/1.1 does not reach the vulnerable code.

The standalone mod_h2 releases 2.0.8 to 2.0.42 are also affected, if you build the module separately from the server.

Affected and fixed versions

Distribution status is as of 12 November 2026. Where no fixed package is available yet, monitor your distribution's security notices and apply the update as soon as it is released.

Version 2.4.71 also fixes two lower-rated issues, CVE-2026-106023 in mod_md (Important) and CVE-2026-109163 in mod_vhost_alias (Low).

How to check whether you are affected

Check the server version:

# Red Hat-based
httpd -v

# Debian and Ubuntu
apache2 -v

Linux distributions often backport security fixes without changing the upstream version number. An httpd version within the upstream affected range does not necessarily mean the installed package is vulnerable. On RHEL 9 and 10, mod_http2 is distributed separately from httpd, and the fix is delivered through that package. Check its installed version against the fixed version listed in the relevant Red Hat advisory:

rpm -qi mod_http2
rpm -q --changelog mod_http2 | grep CVE-2026-119618

For the standard RHEL 9 and RHEL 10 update streams, Red Hat lists mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981) and mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978) as fixed. Extended support and other minor release streams have separate builds, listed on the Red Hat CVE page and the applicable RHSA.

Next, check whether mod_http2 is loaded:

# Red Hat-based
httpd -M | grep http2

# Debian and Ubuntu
apache2ctl -M | grep http2

In upstream Apache, loading mod_http2 does not automatically enable HTTP/2. The Protocols directive defaults to http/1.1.

Debian and Ubuntu commonly enable HTTP/2 through their packaged configuration: enabling mod_http2 with a2enmod http2 also enables http2.conf, which normally contains a Protocols directive allowing h2 and h2c alongside HTTP/1.1. Enabling the module on these distributions can enable HTTP/2 without additional configuration changes.

Search your configuration for Protocols directives containing h2 or h2c:

# Red Hat-based
grep -RniE '^[[:space:]]*Protocols[[:space:]]' /etc/httpd/

# Debian and Ubuntu
grep -RniE '^[[:space:]]*Protocols[[:space:]]' /etc/apache2/

The directive can be set globally or per virtual host, so check every included file, and repeat the checks for reverse proxies and for products that bundle Apache HTTP Server, such as appliances and control panels.

Remediation

Updating is the only complete fix. When you update:

• Restart the server: the running processes keep the old module in memory until Apache is restarted.
• Rebuild containers: replace base images pinned to affected versions, such as httpd:2.4.70, with a patched image. Rebuild and redeploy the containers, then verify the Apache version inside the resulting image.
• Check bundled copies: if a vendor or hosting provider supplies Apache HTTP Server for you, confirm which version is running and when the fix will be applied.

Stop-gap mitigation

If no patched package is available for your distribution yet, you can temporarily disable HTTP/2. Red Hat states that servers serving only HTTP/1.1 are not affected.

Remove h2 and h2c from every applicable Protocols directive (e.g. from Protocols h2 h2c http/1.1), including virtual-host-specific settings, or explicitly configure HTTP/1.1 at each relevant scope. For example:

Protocols http/1.1

Reload or restart Apache for the change to take effect, then verify the effective configuration for every virtual host and confirm that HTTP/2 is no longer negotiated.

Neither Apache nor Red Hat lists this as an official workaround, and clients won't be able to connect via HTTP/2 until this change is reverted. Ensure any changes are tested and validated before deploying to production, and apply the relevant update when possible.

Timeline

• 26 October 2026: Anthropic reports vulnerability
• 3 November 2026: Google Cloud researchers report independently
• 11 November 2026: Fix committed and Apache 2.4.71 released

References

• Apache HTTP Server 2.4 vulnerabilities
• CVE record: CVE-2026-119618
• Red Hat: CVE-2026-119618
• Debian security tracker: CVE-2026-119618
• oss-security: Apache HTTP Server 2.4.71 announcement for CVE-2026-119618

Adam Govier Founder & Lead Consultant

OSCP OSCE

Adam founded Exploitr and leads its penetration testing practice. He holds OSCP and OSCE certifications and has over 12 years' experience in penetration testing and security consulting.