Nomios Threat Intelligence update: Apache HTTP/2 flaw

Last update: 12th November 2026, 16:00

CVE-2026-119618 allows an unauthenticated attacker to run code on a web server. A fix is available and no exploitation has been confirmed. Position as at 12 November 2026.

Nomios Threat Intelligence is tracking CVE-2026-119618, a critical flaw in the HTTP/2 module of Apache HTTP Server. On 11 November the Apache HTTP Server Project released 2.4.71, which fixes three vulnerabilities, and this is the most serious of them.

The flaw is a race condition in mod_http2, the module that provides HTTP/2 support. HTTP/2 lets a client send many requests over one connection, and Apache handles them on several threads. In the assign_headers() function, those threads can write to shared memory without proper locking, which corrupts the heap. This can lead to remote code execution. No login or user interaction is needed, and code would run with the privileges of the web server process.

• Affected: Apache 2.4.55 to 2.4.70, and standalone mod_h2 2.0.8 to 2.0.42
• Found independently by two research teams: Anthropic’s OSS Scanner (26 October) and Google Cloud Vulnerability Research (3 November)
• Crash-reproduction code was published on GitHub on 12 November, one day after disclosure
• 64% of cloud environments have resources running vulnerable versions, and 51% have publicly exposed instances. These figures don’t account for whether HTTP/2 is enabled

Nomios Threat Intelligence has seen no confirmation of exploitation, and the flaw is not in CISA’s Known Exploited Vulnerabilities catalogue. The public code runs the race until an Apache child process crashes. It does not achieve code execution. Sources disagree on how far exploitation has progressed: Red Hat points to public research showing a reliable exploit against a default server with mod_http2 enabled, while other analysts see no working exploit and expect exploitability to be limited. Nomios assesses that the step from crash to code execution could be short, and recommends treating internet-facing servers as a priority.

What “exposed” actually means

HTTP/2 is off by default. A server is exposed if mod_http2 is loaded and the Protocols directive includes h2 or h2c, at server level or in any virtual host. The directive can differ between virtual hosts, so check each one. Servers that only speak HTTP/1.1 are not affected by this flaw.

Many sites enable HTTP/2 for performance, and hosting control panels often offer it as a setting. In many cloud setups, a load balancer or CDN terminates HTTP/2 and passes HTTP/1.1 to Apache, which keeps mod_http2 out of reach from the internet. Some load balancers can use HTTP/2 to the back end, so check that setting, and check for internal h2c listeners.

Servers patched earlier this year are still affected. This is the fourth memory-safety fix in mod_http2 in 2026, and 2.4.67 (CVE-2026-23918, May) and 2.4.69 (CVE-2026-57941, October) both fall within the affected range.

Severity ratings differ. Apache rates the flaw critical but has not published a CVSS score, and NVD had not scored it on 12 November. Red Hat scores it 9.8 and rates it Important on RHEL 9 and 10, because its packages allocate each HTTP/2 stream from a separate memory allocator, which makes exploitation considerably harder.

This is a different issue from HTTP2Shell (CVE-2026-111497), first disclosed as Node2Shell. That flaw is in the Brotli compression library and is unrelated to the HTTP/2 protocol. Fixing one does not fix the other.

Impact of CVE-2026-119618

A successful attack gives the attacker code execution on an internet-facing server, as the web server account. What follows depends on what that server can reach. The main risks are:

• Remote code execution without authentication
• Lateral movement into adjacent services
• In cloud and container environments, access to the instance metadata endpoint
• Service crashes, even where code execution isn’t achieved

What to do now

Find every Apache instance. Include internal applications, reverse proxies, development and staging servers, container images, Windows hosts and software that bundles its own Apache. Check what the running binary reports rather than the asset record.

httpd -v                # apache2 -v on Debian-based systems

apachectl -M | grep http2 

grep -Rni Protocols /etc/httpd /etc/apache2 

curl -sI --http2 https://<host>    # from outside, shows the negotiated protocol

Patch. Start with internet-facing servers that use HTTP/2. Install 2.4.71 or your distribution’s fixed package, do a full stop and start instead of a graceful reload, and confirm the running version. The Apache project doesn’t publish Windows binaries, so get a 2.4.71 build from your binary distributor or the vendor of your bundled stack.

Switch HTTP/2 off where you can’t patch yet. Set Protocols http/1.1 in the server configuration and every <VirtualHost>, or comment out LoadModule http2_module, then restart. Clients fall back to HTTP/1.1 and page loads may be slightly slower. This closes the only path to this flaw on every platform. It does not address the other two flaws fixed in 2.4.71, so you will still need to patch.

Check exposed servers for signs of attack. In the error log, look for groups of child-process crashes (AH00052 with exit signal Segmentation fault or Aborted) that don’t match a deployment or a load spike. Also look for unexpected processes or shells started by the web server account, new files in web roots, and connections from the web server to unfamiliar hosts. If you find any of these, contact the Nomios SOC before patching so evidence is preserved. With crash code public, expect probing. Crashes alone don’t confirm a compromise, and a clean log doesn’t confirm a server is safe.

Where fixes stand by platform

Red Hat. The fix is a separate mod_http2 package, so updating httpd alone isn’t enough. Check with rpm -q mod_http2, then run dnf update mod_http2 and restart httpd. The fixed packages are mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978) for RHEL 10 and mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981) for RHEL 9. EUS and E4S streams have their own advisories. AlmaLinux, Rocky Linux and Oracle Linux publish separate errata, so confirm your distributor has released the equivalent update. Where you can’t update yet, comment out LoadModule http2_module in conf.modules.d/10-h2.conf.

Debian and Ubuntu. mod_http2 is part of the apache2 package and is enabled with a2enmod http2. Until fixed packages are released:

sudo a2dismod http2 sudo systemctl restart apache2 apache2ctl -M | grep -i http2    # should return nothing

By version number, Ubuntu 24.04 (2.4.58), 25.10 (2.4.64) and 26.04 (2.4.66) are in the affected range and 22.04 (2.4.52) is below it. Distributions backport fixes, so use the security tracker for your release rather than the version string.

Cloud and containers. Apache usually runs from images, so the fix is to rebuild from a fixed base image and redeploy. Don’t patch running containers. Until a fixed image exists, set Protocols http/1.1 in the image configuration. Use IMDSv2, keep instance roles to the minimum, and ask managed or shared hosting providers whether they have applied the update or the HTTP/2 change.

The other two flaws in 2.4.71. CVE-2026-106023 (important) allows a request to crash child processes through mod_md, Apache’s ACME certificate module, in 2.4.30 to 2.4.70, with or without HTTP/2. CVE-2026-109163 (low) is a one-byte stack overwrite in mod_vhost_alias in 2.4.69 and 2.4.70. Upgrade even if you don’t use HTTP/2.

Appliances and vendor products

Apache is built into many appliances and enterprise products, usually behind web management interfaces, portals and application front ends. Whether one is exposed depends on the Apache version the vendor ships and whether HTTP/2 is enabled in the build, which customers can rarely see or change. In October, PHP2Shell, a flaw in the PHP engine, reached the management interfaces of several network and security products within days of disclosure and was then exploited against internet-exposed devices.

Nomios Threat Intelligence found no vendor statements on CVE-2026-119618 on 12 November. Ask each vendor in writing whether their product ships Apache 2.4.55 to 2.4.70 with HTTP/2 enabled and when a fix will be available. Until you hear back, assume the product may be affected. Keep management interfaces and admin portals reachable only from a jump host or management network. Don’t change Apache configuration on an appliance unless the vendor documents it, as changes can be lost on upgrade or affect support.

None of the pending vendors has given a date for its fix, so check each vendor’s tracker rather than planning around an expected date. We will update customers as statements appear.

Please don’t run the public crash code against your own servers. It can take production services down.