Apache HTTP Server CVE-2026-119618 (mod_http2 RCE)

On November 11, 2026, Apache HTTP Server 2.4.71 was released to fix CVE-2026-119618, a race condition in mod_http2 that causes heap corruption and can lead to remote code execution (RCE). The Apache project rates it critical. It affects 2.4.55 through 2.4.70, and Red Hat explains that it applies to servers with HTTP/2 (h2 or h2c) enabled, while HTTP/1.1-only setups are not affected.

This article is based on the Apache HTTP Server security page, NVD, the oss-security announcement, Red Hat and Debian security information, CISA KEV and Docker official image tags as of November 12, 2026. Where something could not be confirmed, we say so rather than guess. Other vulnerabilities from the same day are in the November 12 vulnerability digest.

- What happened: mod_http2 in Apache HTTP Server has a race condition (CWE-362) in which threads share memory without proper synchronization; heap corruption in assign_headers() can lead to RCE. Apache rates it critical. NVD had not assigned a CVSS score as of November 12, 2026 (Red Hat assigns its own 9.8).
- Who is affected: servers running Apache HTTP Server 2.4.55 through 2.4.70 with HTTP/2 enabled, and mod_h2 from GitHub 2.0.8 through 2.0.42. Versions up to 2.4.54 and HTTP/1.1-only configurations are not affected.
- What to do today: (1) check your Apache version and whether HTTP/2 is enabled, (2) update to 2.4.71 or your distribution's fixed package and restart, (3) if you cannot update yet, limit Protocols to http/1.1 to turn HTTP/2 off. The vulnerability is not listed in CISA KEV at the time of writing.

The Apache security page states the affected range as "2.4.55 through 2.4.70". "Affected" here means the version includes mod_http2 and HTTP/2 is enabled.

For RHEL 9 and 10 the fix ships as a mod_http2 package update, not a new Apache core. Even if the package version does not look like 2.4.71, a version at or above the one in the table is fixed. Distributions that backport fixes may be patched even when the version number is 2.4.70 or lower.

HTTP/2 lets a connection carry many requests at the same time. In Apache the mod_http2 module handles it, processing concurrent requests on multiple threads.

Apache describes the cause as concurrent execution using a shared resource with improper synchronization (CWE-362, a race condition), with heap corruption in assign_headers() that can lead to RCE. Red Hat is more specific: a worker thread writes into memory owned by the connection thread through a shared, lock-free allocator. Think of two people editing the same sheet of paper at once until it is garbled. If an attacker can steer that corruption, they can take over the server's behavior, which is what RCE means.

According to Red Hat's statement, the flaw is reachable remotely without authentication, and public research has demonstrated a reliable exploit against a default-configured server with mod_http2 enabled. However, the mod_http2 packages in RHEL 9 and 10 allocate each HTTP/2 stream from a separate allocator, which makes exploitation considerably harder, so Red Hat rates them Important rather than Critical. That implementation difference explains why ratings differ between Apache and Red Hat.

Two other issues fixed in 2.4.71 are of a different nature. CVE-2026-106023 is a NULL pointer dereference in mod_md that crashes a child process (important, 2.4.30 to 2.4.70). CVE-2026-109163 is a one-byte stack buffer overwrite in mod_vhost_alias (low, 2.4.69 and 2.4.70). Updating fixes all three.

NVD registered CVE-2026-119618 on November 11, 2026, but its status remained "Received" and no CVSS score had been assigned as of November 12. The Apache CVE record lists severity critical (Apache's rating) and CWE-362. Red Hat assigns its own CVSS 3.1 score of 9.8 (network, no authentication, no user interaction). Scores differ between organizations, so weigh the nature of the flaw, unauthenticated RCE, more than the number.

On exploitation, CVE-2026-119618 is not listed in the CISA KEV catalog (known_exploited_vulnerabilities.json, checked on November 12, 2026), and the Apache security page does not mention confirmed exploitation. Red Hat does say public research has demonstrated an attack, so it is prudent to act as if working exploit code may exist. This can change, so keep checking KEV and vendor information.

Run all checks on servers you manage. Testing a vulnerability against someone else's server is unauthorized access, so do not do that.

Step 1: Check the Apache version. The command name differs by distribution.

You will see "Server version: Apache/2.4.xx". 2.4.55 to 2.4.70 may be affected. Distribution builds may carry fixes under an old version number, so also check the package information in step 3.

Step 2: Check whether mod_http2 is loaded and HTTP/2 is enabled.

If http2_module appears and Protocols includes h2 or h2c, HTTP/2 is likely enabled. A curl result of "HTTP/2 200" means the server really answers in HTTP/2. If there is no Protocols line, or it is only http/1.1, HTTP/2 is not in use. Protocols can also be set per virtual host, so use apachectl -S to find the active virtual host files.

Step 3: Check the package version.

On RHEL 9 and 10, check that the mod_http2 version is at or above the one in the table. For Debian, no fixed package existed at the time of writing, and Ubuntu is unconfirmed, so check regularly for updates.

Step 4: Docker. If you use the official httpd image, check the version of the running container.

We confirmed that 2.4.71 tags (2.4.71, 2.4.71-alpine, 2.4.71-alpine3.24, 2.4.71-trixie) are published on Docker Hub. Tags such as httpd:2.4 change content when new builds are pushed, so pull again, rebuild, and verify that httpd -v shows 2.4.71.

At the time of writing the Debian security tracker listed bookworm (2.4.68-1~deb12u1; security 2.4.67-1~deb12u3), trixie (2.4.68-1~deb13u1; security 2.4.69-1~deb13u1) and forky (2.4.69-1) as vulnerable. Only sid (2.4.71-1) was marked fixed. So no fixed package for the stable releases had been published yet. We could not open the Ubuntu tracker page for this CVE, so its status is unconfirmed. Check each distribution's security information for the fixed package and apply it as soon as it appears.

Until a fix is available, consider the mitigation below (turning HTTP/2 off). On Debian-family systems a2dismod http2 disables mod_http2.

According to Red Hat, fixes for RHEL 9 and 10 were published on November 11, 2026 (RHSA-2026:98981 for RHEL 9, RHSA-2026:98978 for RHEL 10). RHEL 8 and earlier are not affected. We could not confirm whether compatible distributions such as Rocky Linux or AlmaLinux have released equivalent fixes; check their advisories.

The httpd inside an image does not get newer when you restart a container. Move the base to a 2.4.71 tag, rebuild the image and redeploy.

After rebuilding, confirm 2.4.71 with docker exec CONTAINER httpd -v. We could not confirm the fix status of Alpine's own apache2 package at the time of writing.

Download 2.4.71 from the official Apache distribution and rebuild. If you compile mod_http2 in (for example with --enable-http2), it will be the 2.4.71 version. After replacing, check the version with httpd -v and restart the service. The fix commit is listed on the Apache security page as 824beab.

mod_h2 from GitHub (icing/mod_h2) 2.0.8 through 2.0.42 is listed as affected. However, that repository was archived (read-only) on June 9, 2026, the latest release is v2.0.42 (May 29, 2026), and we found no fixed mod_h2 release. If you use standalone mod_h2, look at switching to the mod_http2 bundled with Apache 2.4.71 and check Apache's official information.

If a provider manages your server, you cannot update Apache yourself. Check the provider's notices for their plan for this vulnerability, and ask support if there is none. Ask specifically whether HTTP/2 has been turned off or the server updated for the Apache mod_http2 vulnerability CVE-2026-119618.

Some setups have a CDN or load balancer accept HTTP/2 and talk to the origin server over HTTP/1.1. Apache's official information does not address this setup, but since Red Hat says servers with h2 or h2c enabled via Protocols are affected, an origin Apache without HTTP/2 enabled would reasonably see little exposure on that path. However, if the origin Apache is reachable directly from the internet, attacks can bypass the CDN. Check how widely the origin is exposed as well.

The official Apache security page lists no workaround other than updating. The following are interim measures based on Red Hat's statement that HTTP/1.1-only servers are not affected. They are not fixes; use them only as a bridge until you update.

Option 1: Limit Protocols to http/1.1. Change Protocols so that it does not include HTTP/2.

Check both the server-wide configuration and each VirtualHost for Protocols lines. Remove h2c (unencrypted HTTP/2) too if it is configured. After the change, test the syntax and restart.

Option 2: Disable the mod_http2 module. On Debian family use the command below. On the RHEL family, comment out the LoadModule http2_module ... line.

The side effect is that HTTP/2 is no longer available and browsers connect over HTTP/1.1. The site keeps working, but pages that load many files at once may be slightly slower. If you receive traffic that requires HTTP/2, such as gRPC, through Apache, that traffic will stop working, so check the impact first. Once you have updated, you can restore the original settings.

We could not confirm whether WAF or firewall blocking is effective. Attacks that craft the protocol traffic itself are often not stopped by a WAF, so treat the two options above as the baseline and put updating first.

- Listed every server, container and device running Apache HTTP Server (web servers, internal portals, dev and test environments, admin consoles on NAS or multifunction printers)
- Checked the version with httpd -v (or apache2 -v) on each
- Checked whether HTTP/2 is enabled using apachectl -M | grep -i http2 and the Protocols settings
- Marked servers on 2.4.55 to 2.4.70 with HTTP/2 enabled as top priority
- Updated those with fixed packages and used restart (on RHEL 9 and 10, update mod_http2)
- For those without a fixed package yet (such as Debian stable), set Protocols to http/1.1 or disabled HTTP/2 and decided how to watch for the update
- Rebuilt and redeployed Docker images on a 2.4.71 tag
- Asked hosting providers and contractors about their status
- After updating, confirmed 2.4.71 or the fixed package version with httpd -v
- If a mitigation was used, recorded a plan to revert it after updating
- Checked logs for suspicious access or crashes (below)

When reviewing logs, look in Apache's error_log for signs of child processes ending abnormally (segmentation fault, "child pid ... exit signal" and so on). We found no report of attacks before disclosure, but a failed memory-corruption attack can leave a crash trace. If you see restarts or process anomalies you cannot explain, investigate them as a possible compromise too. For the bigger picture of patching, see the SMB patch and update management guide.

This is not the first HTTP/2-related flaw. The Brotli vulnerability CVE-2026-111497, reported as exploitable over HTTP/2 in Node.js and Python stacks, is another example. HTTP/2 is a complex specification and implementations manage many threads and states, so bugs surface with each new version. Enabling only the features you use, and keeping a ledger of which servers have HTTP/2 enabled, makes decisions faster the next time a similar issue appears.

- Apache HTTP Server 2.4 vulnerabilities (CVE-2026-119618, 2.4.71)
- oss-security: CVE-2026-119618: Apache HTTP Server: mod_http2: heap corruption and RCE in assign_headers (2026-11-11)
- Apache httpd 2.4.71 ChangeLog
- NVD: CVE-2026-119618
- Red Hat: CVE-2026-119618
- Debian Security Tracker: CVE-2026-119618
- Ubuntu Security: CVE-2026-119618
- CISA Known Exploited Vulnerabilities Catalog
- Docker Hub: httpd (official image)
- icing/mod_h2 releases (GitHub)