Apache HTTP/2 RCE (CVE-2026-119618): How to Check and Patch

CVE-2026-119618 is a critical flaw in Apache HTTP Server's HTTP/2 module (mod_http2). It lets a remote attacker with no login corrupt heap memory and potentially run code on servers running versions 2.4.55 through 2.4.70 with HTTP/2 enabled. The fix is Apache 2.4.71, released on November 11, 2026, or your distribution's backported package. If you can't patch today, turning off HTTP/2 closes the hole.

This guide covers how to tell whether you're exposed, what each major platform has shipped so far, and how to mitigate safely while you wait for packages.

What the vulnerability is

According to the official Apache advisory, the bug is "concurrent execution using shared resource with improper synchronization" in the assign_headers() function of mod_http2. Put simply, it's a race condition. When concurrent threads touch the same data without proper locking, the heap can be corrupted, and that can lead to remote code execution with the privileges of the web server process.

Key facts, each checked against the sources linked:

The same 2.4.71 release fixes two more issues listed in the Apache advisory:

• CVE-2026-106023 (important): a NULL pointer dereference in mod_md, the ACME certificate module, that crashes child processes. It affects 2.4.30 through 2.4.70.
• CVE-2026-109163 (low): a one-byte stack buffer overwrite in mod_vhost_alias. It affects 2.4.69 and 2.4.70 and follows up an earlier fix for CVE-2026-63292.

Apache's advice is that almost every 2.4 deployment from 2.4.30 onward is affected by at least one of the three, so upgrading is worthwhile even if you don't use HTTP/2.

How dangerous is it in practice?

The sources don't fully agree on how exploitable it is, and you should know where they differ:

• Red Hat says on its CVE page that "public research has demonstrated a reliable exploit" against a default configuration with mod_http2 enabled. It doesn't link that research. Red Hat also rates the issue Important rather than Critical on RHEL 9 and 10, because each HTTP/2 stream there uses its own memory allocator, which makes exploitation harder.
• Wiz, writing on November 11, said no exploit was available and no in-the-wild exploitation had been reported. Its scans found vulnerable resources in 64% of cloud environments and publicly exposed instances in 51%. Wiz notes those figures don't account for whether HTTP/2 is actually turned on.
• SecurityOnline lists all three CVEs as "not exploited" at publication.

The reasonable conclusion: as of November 12, 2026, nobody has publicly confirmed attacks. But the bug is pre-auth, network-reachable and scored 9.8, and at least one vendor says a reliable exploit exists. Treat it as patch-now.

This is also the second serious mod_http2 bug this year. The Hacker News notes that CVE-2026-23918 was fixed in 2.4.67 on May 4, 2026. Servers you upgraded to 2.4.67–2.4.70 for that one are still vulnerable to this one.

Step 1: Find out whether you're exposed

You're exposed if all three of these are true: your Apache version is in range, mod_http2 is loaded, and HTTP/2 is enabled for at least one listener or virtual host.

1. Check the version.

   apachectl -v        # Debian/Ubuntu
   httpd -v            # RHEL/Fedora/Alpine
   

   Distribution packages often backport fixes without moving to 2.4.71, so a version string alone isn't proof either way. Check your package changelog against the vendor advisory (see the table below).

2. Check whether mod_http2 is loaded.

   apachectl -M 2>/dev/null | grep -i http2
   

   If http2_module doesn't appear, the vulnerable code isn't running.

3. Check every Protocols directive. It can be set server-wide and per virtual host, so search the whole config tree:

   grep -RniE '^\s*Protocols' /etc/apache2 /etc/httpd 2>/dev/null
   

   Any line containing h2 (HTTP/2 over TLS) or h2c (cleartext HTTP/2) means that listener is in scope. Red Hat states that HTTP/1.1-only servers are not affected.

4. Test from the outside, against the origin.

   curl -so /dev/null -w '%{http_version}\n' --http2 https://your-origin.example.com/
   curl -so /dev/null -w '%{http_version}\n' --http2-prior-knowledge http://your-origin.example.com/
   

   A result of 2 means HTTP/2 is negotiated. Run the test against the origin's IP or internal hostname, not just the public domain. If a CDN or load balancer terminates HTTP/2, the public hostname will report 2 even when Apache itself only speaks HTTP/1.1, and the reverse can also happen.

Don't forget the less obvious Apache installs

• Containers. Images built FROM httpd:2.4 or pinned to an older tag carry whatever Apache was current at build time. You have to rebuild, not just restart.
• Bundled stacks. Control panels, appliance images, XAMPP-style dev stacks and vendor products sometimes ship their own httpd build. Those update on the vendor's schedule, not your OS's.
• Internal services. An Apache that only faces your VPC is still reachable by anything that has a foothold inside. Wiz points out that a compromised Apache instance can be a jumping-off point to neighbouring microservices or cloud metadata endpoints.

Step 2: Patch, by platform

Status as of November 12, 2026, compiled from the Debian security tracker, Red Hat, Docker Hub and The Hacker News' roundup:

On RHEL, the fix ships in the separate mod_http2 package rather than httpd, so updating only httpd isn't enough. After any update, restart rather than reload so that every child process runs the new code, and re-run the checks in Step 1.

Standalone mod_h2 builds

If you compile the GitHub mod_h2 module yourself, be careful. Wiz says to upgrade past 2.0.42, but its own version table disagrees with that, and other write-ups mention a 2.0.43 build. The Hacker News reports that no fixed standalone release has been published and that the repository has been read-only since it was archived on June 9. Until you can confirm a patched module from a source you trust, either switch to the mod_http2 bundled with httpd 2.4.71 or turn off HTTP/2.

Step 3: Mitigate if you can't patch today

Apache's advisory doesn't list a workaround, but disabling HTTP/2 removes the vulnerable code path from reach. Wiz recommends this and Red Hat's applicability statement backs it up.

1. In every file Step 1 flagged, change the directive to:

   Protocols http/1.1
   

   Do this in the global config and in each VirtualHost block that sets its own Protocols.
2. Optionally, stop loading the module entirely so a forgotten vhost can't turn it back on. Use a2dismod http2 on Debian/Ubuntu, or comment out the LoadModule http2_module line on RHEL-family systems. Don't do this if the config uses HTTP/2-only directives (for example H2Push) that aren't wrapped in IfModule guards, or Apache won't start.
3. Validate and reload:

   apachectl configtest && apachectl graceful
   

4. Run the curl checks again and confirm they report 1.1.

What it costs you

Browsers and HTTP clients fall back to HTTP/1.1 on their own, so nothing should break functionally. The trade-off is performance. You lose multiplexing, so pages with many assets need more connections, and latency goes up on high-RTT links. If a CDN terminates HTTP/2 for visitors, most users won't notice, because the CDN-to-origin hop is often HTTP/1.1 anyway. gRPC-over-Apache setups and anything else that requires HTTP/2 end to end will break. Find those before you flip the switch, and prioritize patching them instead.

Step 4: Check for signs of compromise

No indicators of compromise had been published as of November 12. Without them, stick to the basics on any host that was exposed with HTTP/2 enabled:

• Look for unexpected httpd child segfaults in the error log (AH00052: child pid ... exit signal Segmentation fault). A sudden cluster of them on a quiet server is worth a look, because racing a heap bug usually produces crashes before it succeeds.
• Look for processes spawned by the web server user (www-data, apache) that don't belong there: shells, curl/wget, crypto miners.
• On cloud hosts, review recent access to the instance metadata service and the use of any credentials attached to the instance role.
• Make sure your EDR or runtime security tool covers web-server hosts and containers, not just laptops.

If you find anything suspicious, rotate the secrets that process could read (database credentials, API keys in environment variables, TLS private keys) and rebuild the host rather than cleaning it in place.

What to watch next

• Distro advisories. Debian stable, Ubuntu and Amazon Linux fixes were still pending on November 12. Subscribe to their security lists and remove the HTTP/2 workaround only once you've installed a fixed package.
• Public exploit code. Red Hat already says a reliable exploit has been shown. If proof-of-concept code turns up on GitHub or in scanners, expect mass scanning within days, so anything still unpatched by then should have HTTP/2 off.
• AI-found bugs keep arriving. Anthropic's OSS Scanner found this one, and Google's team found it independently a week later. Two independent discoveries of the same bug within days suggests memory-safety bugs in widely deployed C servers are being found faster than before. Plan for more frequent emergency patches to your web tier, not fewer: pin and rebuild container images on a schedule, and keep a tested "disable HTTP/2" change ready to deploy.

For more patch guides like this one, see the LaunchBoosts blog.