What happened
On November 11, 2026, the Apache HTTP Server project released version 2.4.71, which fixes CVE-2026-119618. The flaw sits in mod_http2, the module that handles the HTTP/2 protocol, in the assign_headers() function. The Apache security team rates it critical and says it can lead to remote code execution.
The flaw was reported on October 26, 2026 by Anthropic’s OSS Scanner, a free service that uses Anthropic’s AI models to scan open-source projects. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it independently on November 3, 2026.
Nobody has confirmed real-world exploitation so far. The flaw is not in the CISA KEV catalog, and the EU vulnerability database EUVD (entry EUVD-2026-123532) does not list it as exploited. According to The Hacker News, security company Wiz said on November 11 that no exploit was available and no attacks had been reported. Red Hat’s assessment, however, says public research has demonstrated a reliable exploit against a server in its default configuration with mod_http2 enabled, though it does not name that research.
Why it is dangerous
This is a race condition (CWE-362). The server handles many things at once, and two parts of the program work on the same memory without proper coordination. Picture two clerks filling in the same form at the same time: each overwrites part of what the other wrote, and the result is garbage. Here that corrupts the server’s memory (Apache calls it heap corruption), and an attacker can turn that corruption into running their own code.
According to Red Hat, which ships Apache as part of Red Hat Enterprise Linux, the attacker needs no login. They only need to reach the server over the network, which for a public website means over the internet. If they succeed, they could take full control of the server process. That would give them access to everything the Apache process can see, such as website files and configs holding database passwords. From there they could try to move further into the network.
CVSS is an international severity scale from 0 to 10. The US National Vulnerability Database (NVD) has not scored the flaw yet. Red Hat rates it 9.8 out of 10, according to The Hacker News, which is close to the maximum.
For its own RHEL 9 and 10 packages, though, Red Hat rates it only “Important”, because its build of mod_http2 gives each HTTP/2 stream its own memory allocator, which makes an attack much harder. The CISA KEV catalog is the list of flaws the US agency CISA tracks as actively exploited. This flaw is not on it yet.
Who is affected
Affected are Apache HTTP Server 2.4.55 through 2.4.70 and the standalone mod_h2 module from GitHub, versions 2.0.8 through 2.0.42. According to Red Hat, only servers with HTTP/2 enabled are at risk. That is controlled by the Protocols directive (h2 means HTTP/2 over TLS, h2c means unencrypted HTTP/2), which can be set for the whole server or for a single virtual host.
Apache is one of the most widely used web servers. It runs on shared web hosting, company websites, online shops, intranets and as a reverse proxy in front of applications. HTTP/2 is typically enabled on HTTPS sites.
Linux distributions use their own package version numbers. Status according to The Hacker News:
- Red Hat Enterprise Linux 6, 7 and 8: not affected, they do not contain the vulnerable code
- Red Hat Enterprise Linux 9 and 10: affected, fix released
- Red Hat JBoss Core Services and Red Hat Hardened Images: affected, no fix listed yet
- Debian bookworm, trixie and forky: vulnerable, no fix listed yet. Debian unstable (sid) is fixed
- Amazon Linux 2, Amazon Linux 2023 and Amazon Linux 2027 Preview: fix pending
- Ubuntu: had no status page for the flaw as of November 12, 2026
Note: if you updated to 2.4.67 or any later version up to 2.4.70 because of the earlier HTTP/2 flaw (CVE-2026-23918), you are still affected by the new one.
How to check if you are affected
First find out your Apache version. Depending on the system, use one of these commands:
apachectl -v # or: httpd -v, apache2ctl -v
With distribution packages, the package version matters, not just the Apache number:
rpm -q httpd mod_http2 # Red Hat and derivatives
dpkg -l apache2 # Debian, Ubuntu
Then check whether the HTTP/2 module is loaded and where it is enabled:
apachectl -M | grep http2
grep -Rni "Protocols" /etc/httpd/ /etc/apache2/ 2>/dev/null
If Protocols includes h2 or h2c in the main config or in any virtual host, and your version is in the affected range, the server is at risk. You can also confirm HTTP/2 from the outside (a result of 2 means HTTP/2):
curl -s -o /dev/null --http2 -w '%{http_version}\n' https://your-domain.com
On managed web hosting you usually cannot run these commands. Ask your provider whether they already run a fixed Apache.
How to fix it
Apache fixes the flaw in version 2.4.71, released November 11, 2026. That release also fixes a crash in mod_md (rated important) and a one-byte memory overwrite in mod_vhost_alias (rated low). Fixed distribution packages, according to The Hacker News:
- Red Hat Enterprise Linux 9: mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981)
- Red Hat Enterprise Linux 10: mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978)
- RHEL 9.4 Update Services for SAP Solutions and 9.6, 9.8, 10.0 and 10.2 Extended Update Support: RHSA-2026:98968, RHSA-2026:98954, RHSA-2026:98982, RHSA-2026:98953 and RHSA-2026:98979
- Debian unstable (sid): apache2 2.4.71-1
Work in this order:
- Start with internet-facing servers that have HTTP/2 enabled.
- Install your distribution’s update (for example
dnf update httpd mod_http2orapt update && apt upgrade), or move to Apache 2.4.71 if you build it yourself. - Check the config with
apachectl configtestand restart Apache so the new module is loaded. - Verify the version again as described in the previous section.
If no update exists for your system yet (for example Debian bookworm, trixie and forky, Amazon Linux or JBoss Core Services), note that Apache offers no workaround. Security company Wiz advises turning HTTP/2 off: remove h2 and h2c from the Protocols directive, leaving only this:
Protocols http/1.1
Make the change in the main config and in every virtual host, then restart Apache. Sites keep working over HTTP/1.1. The standalone mod_h2 from GitHub has no fixed release and the project has been archived since June 9. According to The Hacker News, the same Protocols change also applies to servers that use this module. In the long run, consider switching to the mod_http2 that ships with Apache 2.4.71.
What if you may already be compromised
Neither Apache nor other sources have published specific indicators of compromise, and nobody has confirmed real-world attacks. Still, if a server with a vulnerable version and HTTP/2 enabled was exposed to the internet, check:
- the Apache error log (
/var/log/httpd/error_logor/var/log/apache2/error.log), where repeated child process crashes, such as “Segmentation fault” messages, may point to attempts at memory corruption - processes running as the Apache user (
apacheorwww-data) that do not belong there, such as a shell or unknown programs - new or changed files in web directories and in
/tmp, especially scripts you did not upload - unknown user accounts, SSH keys and scheduled tasks (cron)
- unusual outbound connections from the server
If you find anything suspicious, updating alone is not enough. Isolate the server from the network, preserve the logs and bring in an incident response specialist. Also change any passwords and keys stored on the server, such as database credentials.
Sources
- Apache HTTP Server 2.4 vulnerabilities - The Apache HTTP Server Project ↗
- oss-security - CVE-2026-119618: Apache HTTP Server: mod_http2: heap corruption and RCE in ↗
- The Hacker News: Critical Apache HTTP/2 Flaw Could Let Unauthenticated Attackers Execute Code Remotely ↗
- NVD CVE-2026-119618 ↗
- ENISA EUVD EUVD-2026-123532 ↗