Apache HTTP/2 Flaw CVE-2026-119618: Update to 2.4.71

What is CVE-2026-119618?

CVE-2026-119618 is a critical vulnerability in mod_http2, the module that handles HTTP/2 traffic in Apache HTTP Server; it can lead to heap corruption and remote code execution ^[1].

Apache describes it as a "Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers()" that "can lead to RCE" ^[1]. CIRCL, Luxembourg's national computer emergency response team, explains that during concurrent processing of HTTP/2 streams, a worker can modify a header table allocated for another execution context, and this unsafe access to shared memory can corrupt the heap ^[2].

A successful attacker could run code with the privileges of the Apache web server process, without logging in ^[2][4]. Apache HTTP Server is estimated to run roughly one in five websites, according to BleepingComputer ^[4].

The upstream fix changes a single write in modules/http2/h2_request.c from the shared request header table to the current request's own input headers ^[2].

Which Apache versions are affected?

Apache HTTP Server 2.4.55 through 2.4.70 is affected, along with standalone mod_h2 releases 2.0.8 through 2.0.42 from GitHub; version 2.4.71 fixes it ^[1].

Distribution packages complicate the version check. CIRCL advises organisations using distributor-maintained packages to verify the security backport rather than rely only on the upstream version number ^[2]. Red Hat, as summarised by CIRCL, rates its RHEL 9 and 10 packages Important rather than Critical because their memory allocator makes exploitation harder, and reports RHEL 8 and earlier as not affected ^[2].

Red Hat gives a general CVSS v3.1 score of 9.8 (Critical) ^[2][3]. Apache's own rating is Critical ^[1].

Is my Apache server vulnerable?

Only if it runs an affected build and actually accepts HTTP/2 connections: Red Hat says servers configured to serve only HTTP/1.1 are not vulnerable ^[3]. CIRCL stresses that the code path is not reachable merely because mod_http2 is installed or loaded ^[2].

• The Protocols directive controls HTTP/2: "h2" enables it over TLS and "h2c" over cleartext ^[2].
• Apache's core default is http/1.1, and loading mod_http2 does not change that by itself ^[2]. BleepingComputer notes HTTP/2 is off by default ^[4].
• A virtual host can set its own Protocols directive, so checking only the global configuration can miss an HTTP/2-enabled site ^[2].
• If a reverse proxy, load balancer or CDN terminates HTTP/2 and forwards only HTTP/1.1 to Apache, the client's HTTP/2 session does not by itself make Apache reachable, but you should verify the protocol on each hop ^[2].

CIRCL suggests reviewing the version and loaded modules (apachectl -v, apachectl -M), the configured virtual hosts (apachectl -S) and every explicit Protocols setting ^[2]. A test showing an endpoint accepts HTTP/2 does not prove its backend is vulnerable, and a negative test does not prove every port or virtual host rejects HTTP/2 ^[2].

How do I check whether my server accepts HTTP/2?

CIRCL suggests two checks: review the Apache configuration on the server itself, then test the negotiated protocol from the network, ideally connecting directly to Apache rather than through a proxy ^[2].

1. Check the version and modules. Run apachectl -v to see the version and apachectl -M, filtered for http2, to see whether the module is loaded ^[2].
2. List virtual hosts. apachectl -S shows every configured virtual host, which matters because each can carry its own Protocols line ^[2].
3. Find every Protocols directive. CIRCL gives a grep command that searches /etc/apache2 and /etc/httpd for explicit Protocols settings, including virtual-host overrides; paths vary by distribution ^[2].
4. Test over TLS. A curl request with the --http2 option that prints the HTTP version shows whether an HTTPS endpoint negotiates HTTP/2 ^[2].
5. Test cleartext. curl with --http2-prior-knowledge checks whether a plain HTTP endpoint accepts h2c ^[2].

Read results carefully. A response reporting HTTP/2 shows the tested endpoint accepted HTTP/2 but does not confirm that its Apache backend is vulnerable; a negative result does not prove that every address, port or virtual host rejects it ^[2]. CIRCL's advice is to confirm the effective Apache configuration and the vendor's patched-package status together ^[2]. In cloud setups, Wiz warns that a compromised Apache instance can become an entry point for lateral movement to nearby microservices or cloud metadata endpoints, which is another reason to check every instance rather than only the public website ^[5].

How do I fix CVE-2026-119618?

Upgrade to Apache HTTP Server 2.4.71 or later, or install your distribution's patched package, then restart Apache and confirm the running processes use the new build ^[2][1].

1. Update Apache. Install 2.4.71 or a vendor build explicitly patched for CVE-2026-119618 ^[2].
2. Update standalone mod_h2 if you use it, as directed by its vendor; Wiz says to move beyond 2.0.42, while CIRCL warns not to assume a newer standalone release exists without checking ^[5][2].
3. Restart and verify that running processes use the corrected build ^[2].
4. If you cannot patch yet, disable HTTP/2: set Protocols to http/1.1, remove h2 and h2c from every overriding virtual host, test with apachectl -t and reload ^[2]. This blocks this flaw's path but does not fix the code ^[2].
5. Restrict access to trusted networks as a temporary measure where neither patching nor protocol changes are possible ^[2].

Researchers at watchTowr summed it up as "patch now or drop h2 until you can," BleepingComputer reports ^[4]. SecurityWeek reports that Defiant also warned that WordPress security updates cannot resolve the issue because it affects the underlying web server ^[3].

Is CVE-2026-119618 being exploited?

As of Wiz's post on 11 November 2026, no exploit was available and there were no reports of exploitation in the wild ^[5]. The picture is moving quickly, though.

• Red Hat says public research has demonstrated a reliable exploit against a server with mod_http2 enabled, but its advisory does not identify the research ^[3]. CIRCL notes that this does not, by itself, establish exploitation in the wild ^[2].
• A public proof of concept on GitHub reports reproducing memory corruption and Apache crashes, but does not demonstrate remote code execution ^[3].
• Wiz data shows 64% of cloud environments contain resources running affected versions and 51% have publicly exposed instances; Wiz notes this does not account for configuration, so these are not necessarily exploitable systems ^[5][3].

CIRCL lists signs worth investigating: unexpected worker crashes, abnormal restarts, suspicious child processes, unauthorised file changes and unexpected outbound connections ^[2]. These are leads, not confirmed indicators of compromise, and patching does not remove persistence set up before the update ^[2].

Who found the Apache HTTP/2 flaw?

Apache credits Anthropic's OSS Scanner, which reported the flaw on 26 October 2026, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research, who reported it independently on 3 November ^[1].

The Anthropic finding is listed under the internal identifier ANT-2026-MAPKT6MZ ^[1]. SecurityWeek describes the two reports as independent discoveries ^[3]. It is another example of automated and AI-assisted tools finding serious bugs in widely used open-source software; AI That Finds Security Bugs: What Glasswing and New CVEs Mean for You looks at what that trend means.

The fix was committed and 2.4.71 released on 11 November, the same day Apache disclosed the issue on the oss-security mailing list ^[1][2].

What else does Apache 2.4.71 fix?

Apache HTTP Server 2.4.71 fixes three CVEs in total: one critical, one important and one low ^[1].

• CVE-2026-106023 (important): a NULL pointer dereference in mod_md during request processing that can crash a child process; affects 2.4.30 through 2.4.70 ^[1].
• CVE-2026-109163 (low): a one-byte stack buffer overwrite in mod_vhost_alias, which Apache labels "after CVE-2026-63292" (that earlier flaw was fixed in 2.4.69); affects 2.4.69 and 2.4.70 ^[1].

The previous release, 2.4.69 in October 2026, fixed 20 CVEs ^[1]. Admins who skipped it get those fixes too by moving to 2.4.71. For another recent server flaw, see CVE-2026-98432 Explained: The Linux TCP Flaw and How to Protect Your Servers.

What should admins watch next?

Watch for a public remote-code-execution exploit, vendor backports for your distribution and any reports of attacks in the wild ^[3][5].

CIRCL recommends inventorying HTTP/2-enabled instances, checking whether each mod_http2 build is affected and patching exposed systems without delay, with priority for internet-facing websites, APIs, shared hosting and Apache servers behind frontends that forward HTTP/2 ^[2]. Organisations that see suspicious activity should follow their incident-response procedures and contact their national CSIRT ^[2].