The Apache Software Foundation has released Apache HTTP Server 2.4.71 to fix CVE-2026-119618, a critical race condition in the mod_http2 module that can lead to Remote Code Execution (RCE). Any server running httpd 2.4.55 through 2.4.70 with HTTP/2 enabled is in scope, and the attacker needs no credentials or user interaction.
No active exploitation attempts or compromises have been observed to date. However, patch availability across Linux distributions remains varied, with certain vendors delivering security updates swiftly while others continue to mark packages as vulnerable or pending.
Where Does the Bug Sit in mod_http2?
Apache describes the flaw as concurrent execution using a shared resource with improper synchronization in the assign_headers() function of mod_http2. In plain terms, two threads handling HTTP/2 traffic can touch the same memory without proper coordination, so one thread ends up writing into memory that belongs to another. The result is heap corruption, which an attacker who can shape the timing and content of requests may be able to steer toward code execution.
Apache has not published the request sequence that triggers the race, and the fix commit is the only public technical detail from the project. Code execution would most likely run in the context of the httpd worker process, typically an unprivileged service account; reaching root would require a separate privilege escalation.
Which Versions and Configurations Are Affected?
| Component | Affected | Fixed |
|---|---|---|
| Apache HTTP Server (bundled mod_http2) | 2.4.55 through 2.4.70 | 2.4.71 (released November 11, 2026) |
| Standalone mod_h2 module | 2.0.8 through 2.0.42 | No fixed release; the GitHub repository has been archived |
Exposure depends on configuration. The server must load mod_http2 and list h2 (HTTP/2 over TLS) or h2c (cleartext HTTP/2) in its Protocols directive, either server-wide or in a single virtual host. HTTP/2 runs only where that directive turns it on, but control panels, hosting templates and performance tuning guides can switch it on without much visibility.
Servers that upgraded to 2.4.67 through 2.4.70 to fix earlier mod_http2 issues remain vulnerable to this one. CVE-2026-119618 is at least the fifth mod_http2 flaw Apache has fixed in 2026, after CVE-2026-23918, CVE-2026-48913, CVE-2026-49975 and CVE-2026-57941.
How Severe Is CVE-2026-119618?
Apache rates the flaw critical without publishing a numeric score. Red Hat assigns it a CVSS 3.1 base score of 9.8, reflecting a network attack with low complexity and no privileges or user interaction required.
Red Hat’s own product rating is lower. It classifies the issue as Important for RHEL 9 and RHEL 10 because its builds give each HTTP/2 stream a separate memory allocator, which the company says makes exploitation much harder. RHEL 8 and earlier are not affected. That difference is a reminder that real-world risk depends on how each distribution builds the module, not only on the upstream score.
Has Anyone Weaponized CVE-2026-119618 Yet?
The evidence is mixed, so it helps to separate the claims:
- Red Hat’s statement: Red Hat says public research has demonstrated a reliable exploit against a default-configured server with mod_http2 enabled, but it has not named or linked that research
- Independent checks: Other researchers who looked for the exploit could not locate a public proof of concept, and no working PoC has been independently verified as of November 13, 2026
- In-the-wild activity: No exploitation attempts or compromises have been reported
- CISA KEV: CVE-2026-119618 is not in the Known Exploited Vulnerabilities catalog as of November 13, 2026
One secondary analysis suggests the demonstrated exploit targets the event MPM and depends on threading and memory allocator behavior. That detail has not been confirmed, but it is consistent with Red Hat’s view that allocator design affects exploitability.
Who Found the Flaw, and How Fast Was the Fix?
Apache credits two independent reports. Anthropic’s AI-based OSS Scanner reported the issue on October 26, 2026, and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it on November 3. The fix and the 2.4.71 release followed on November 11, 16 days after the first report.
The 2.4.71 release also fixes two lower-severity flaws:
| CVE | Severity | Module | Issue | Affected |
|---|---|---|---|---|
| CVE-2026-119618 | Critical | mod_http2 | Race condition leading to RCE | 2.4.55 to 2.4.70 |
| CVE-2026-106023 | Important | mod_md | NULL pointer dereference crashing a child process | 2.4.30 to 2.4.70 |
| CVE-2026-109163 | Low | mod_vhost_alias | 1-byte stack buffer overwrite | 2.4.69 to 2.4.70 |
Where Do Linux Distribution Packages Stand?
Most production servers run distribution packages, not upstream builds, and the status varied widely as of November 12 and 13:
- Red Hat: Fixed for RHEL 9 in mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981) and for RHEL 10 in mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978); JBoss Core Services and Red Hat Hardened Images were listed as affected without a fix
- Debian: Fixed in sid (2.4.71-1) and in trixie through DSA-6620-1 (2.4.71-1~deb13u1); bookworm and forky were still listed as vulnerable
- Amazon Linux: AL2, AL2023 and the AL2027 preview were marked pending fix
- Ubuntu: No CVE page or security notice had been published
Distributions often backport security fixes without changing the upstream version string. A scanner that flags every httpd below 2.4.71 will produce false positives on patched distribution builds, so confirm fixes against each vendor’s advisory or package changelog.
What If Patching Has to Wait?
Apache’s advisory lists no workaround. The approach suggested by researchers is to remove h2 and h2c from the Protocols directive, leaving Protocols http/1.1, or to unload mod_http2 entirely until a fixed package is installed. Check every virtual host, since a single block that re-enables HTTP/2 keeps the server exposed.
Before making that change, confirm that no service depends on HTTP/2. gRPC backends and applications that rely on h2c upgrades will break when HTTP/2 is turned off. Clients that negotiate HTTP/2 through ALPN fall back to HTTP/1.1 automatically.
How Can SOCRadar Help?
Prioritizing CVE-2026-119618 starts with locating exposed Apache servers and understanding which need closer review.
- SOCRadar Exposure Management: Helps teams discover internet-facing Apache servers across their domains and subsidiaries, including overlooked hosts missing from internal inventories
- SOCRadar Cyber Threat Intelligence: Tracks exploit availability, KEV changes, and reported attack activity associated with CVE-2026-119618, helping teams adjust patching priorities as new evidence emerges
Together, these capabilities help teams narrow their investigation and prioritize remediation. Confirm HTTP/2 settings and installed package builds through host-level checks and vendor advisories.
Practical Steps for Web Server Teams
- Patch first: Upgrade to Apache httpd 2.4.71 or install the fixed distribution package as soon as it is available
- Map HTTP/2 usage: Search configurations for Protocols lines containing h2 or h2c and for loaded mod_http2, including in control panel templates and containers
- Disable HTTP/2 where fixes lag: Fall back to HTTP/1.1 on hosts without a fixed package, after checking for gRPC or h2c dependencies
- Replace standalone mod_h2: Move off the archived standalone module, which has no fixed release
- Watch for crash patterns: Repeated child process segmentation faults in the httpd error log, especially on HTTP/2 traffic, are worth investigating; for a memory corruption bug, a version and configuration audit is more reliable than any single network signature
Source: SOCRadar · 2026-11-13