CVE-2026-119618: Critical Apache HTTP/2 Flaw Enables Remote Code Execution

Apache has released an urgent security update addressing CVE-2026-119618, a critical remote code execution vulnerability in the mod_http2 module of Apache HTTP Server. The flaw affects Apache HTTP Server versions 2.4.55 through 2.4.70 and can allow an unauthenticated remote attacker to corrupt heap memory and potentially execute arbitrary commands on vulnerable servers.

The vulnerability stems from improper synchronization when Apache processes concurrent HTTP/2 requests. Multiple threads can access shared resources without sufficient coordination, creating a race condition that allows one thread to modify memory being used by another. Successful exploitation can corrupt the server’s internal heap and ultimately lead to remote code execution.

Only Apache deployments with HTTP/2 enabled are exposed to the known attack path. Servers configured exclusively for HTTP/1.1 do not reach the vulnerable mod_http2 functionality. HTTP/2 can be enabled using h2 for TLS connections or h2c for cleartext HTTP/2 through Apache’s Protocols directive.

Contact Sales

Apache addressed the vulnerability in HTTP Server 2.4.71, released on November 11, 2026. Standalone releases of mod_h2 from GitHub versions 2.0.8 through 2.0.42 are also affected. Apache’s official advisory does not currently identify a separately released fixed standalone mod_h2 version.

Red Hat has assigned the vulnerability a CVSS 3.1 score of 9.8 for its general assessment, with network-accessible, low-complexity exploitation requiring neither authentication nor user interaction. Red Hat further states that research has demonstrated reliable exploitation against a default-configured server with mod_http2 enabled.

However, as of November 12, 2026, neither Apache nor the reviewed security reports document exploitation in real-world attacks. Wiz likewise reported no known in-the-wild exploitation at publication time. Organizations should nevertheless prioritize remediation because the vulnerability is remotely reachable and its technical root cause is now public.

Organizations can strengthen defenses against emerging exploitation with SOC Prime’s AI-Native Detection Intelligence Platform, enabling security teams to operationalize threat intelligence and accelerate detection engineering and threat hunting across SIEM, EDR, XDR, and Data Lake environments.

Detect CVE-2026-119618 by identifying vulnerable internet-facing Apache servers with HTTP/2 enabled and correlating suspicious HTTP/2 activity with Apache crashes, abnormal child processes, unexpected command execution, newly created files, and unusual outbound network connections.

Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.

CVE-2026-119618 analysis

CVE-2026-119618 affects Apache HTTP Server versions 2.4.55 through 2.4.70 when the vulnerable mod_http2 functionality is present and HTTP/2 is enabled. The standalone mod_h2 project is affected from version 2.0.8 through 2.0.42. Apache classifies the issue as critical and maps it to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization.

The vulnerability exists in the assign_headers() function used by Apache’s HTTP/2 processing.

HTTP/2 differs significantly from HTTP/1.1 because multiple streams can operate concurrently over a single connection. Apache’s mod_http2 module therefore uses several threads to process requests and manage HTTP/2 streams simultaneously.

The problem occurs when these threads interact with shared memory without sufficient synchronization. According to Red Hat’s technical assessment, an HTTP/2 stream worker can write into memory owned by the connection thread through a shared, lock-free allocator.

Under attacker-controlled timing, concurrent access can corrupt the heap.

Heap corruption vulnerabilities can have different outcomes depending on memory layout and attacker control. Failed exploitation may cause Apache worker processes to crash, while a sufficiently controlled corruption can modify program state or redirect execution.

Red Hat states that successful exploitation can allow an unauthenticated attacker to execute arbitrary commands with the privileges of the Apache HTTP Server process. This can give attackers access to application data, configuration files, credentials available to the web server, and other resources accessible under that security context.

The vulnerability is particularly concerning on internet-facing systems because no valid account, password, API key, or other authentication is required. An attacker only needs network access to an affected HTTP/2 endpoint.

Exposure nevertheless depends on configuration.

Apache HTTP Server must actually offer HTTP/2. Administrators can enable this through the Protocols directive using:

Protocols h2 http/1.1

for HTTP/2 over TLS, or:

Protocols h2c http/1.1

where cleartext HTTP/2 is supported.

The directive can be configured globally or on individual virtual hosts, meaning administrators should inspect both server-wide and per-site configurations when assessing exposure.

A server that runs an affected Apache version but serves only HTTP/1.1 is not vulnerable through this flaw. Red Hat specifically confirms that systems without HTTP/2 enabled do not reach the affected code path.

Apache’s upstream affected range should also not be applied blindly to Linux distribution packages.

Red Hat Enterprise Linux 8 and earlier releases do not contain the vulnerable code and are not affected. RHEL 9 and RHEL 10 do include affected mod_http2 packages, but Red Hat rates the issue Important rather than Critical on those platforms.

The difference comes from implementation details. On RHEL 9 and 10, each HTTP/2 stream receives a separate memory allocator rather than sharing the same allocator with the connection. Red Hat states that this architecture substantially increases exploitation complexity, although affected systems still require security updates.

Red Hat released corrected packages for multiple RHEL 9 and RHEL 10 streams on November 11. Administrators using vendor-maintained Linux packages should apply their distribution’s security update instead of determining vulnerability solely from the upstream Apache version displayed by the server.

Apache HTTP Server 2.4.71 provides the upstream correction. The fix modifies the vulnerable synchronization and memory-management behavior so that concurrent HTTP/2 operations cannot interact with the affected shared resources in the unsafe manner.

The vulnerability was independently discovered through two research efforts.

Anthropic’s OSS Scanner reported the issue to Apache’s security team on October 26, 2026 under identifier ANT-2026-MAPKT6MZ. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research independently reported the vulnerability on November 3. Apache released the fix on November 11.

The CVE record was published on November 11, 2026.

The CVE-2026-119618 PoC situation requires careful interpretation. Red Hat states that public research demonstrated a reliable exploit against a default-configured server with mod_http2 enabled. However, The Hacker News and Wiz reported that no publicly available RCE exploit had been identified when their reports were published. Public GitHub projects claiming scanners or exploitation-related tooling should therefore not automatically be interpreted as validated weaponized RCE code.

This distinction matters operationally. Defenders should assume the flaw is technically exploitable while avoiding claims that a reliable weaponized exploit is already circulating broadly unless further evidence emerges.

For CVE-2026-119618 detection, security teams should first identify exposed systems rather than relying only on exploit signatures.

Administrators can confirm whether the HTTP/2 module is loaded using:

apachectl -M | grep http2

They should then inspect Apache configuration files for Protocols directives containing h2 or h2c, including directives defined inside individual virtual hosts.

External service discovery can also identify servers negotiating HTTP/2 through TLS ALPN. However, version identification alone can be misleading because Linux distributions frequently backport vulnerability fixes without changing the upstream-looking version string.

Runtime telemetry should be correlated with suspicious HTTP/2 traffic. Potential behavioral indicators include repeated Apache worker crashes, segmentation faults, abnormal restarts, memory-corruption messages, or sudden service instability associated with unusual HTTP/2 request bursts.

Because successful exploitation can provide command execution, endpoint and host telemetry should also be reviewed for unusual child processes originating from Apache.

Examples include httpd or apache2 unexpectedly launching shells, scripting interpreters, download utilities, or system administration commands.

Security teams should investigate process relationships such as:

httpd → /bin/sh

apache2 → bash

httpd → curl

apache2 → wget

or other execution chains inconsistent with the hosted application’s normal behavior.

File creation within temporary directories, web roots, startup locations, or writable application folders can also indicate post-exploitation activity. Unexpected outbound connections from Apache worker processes should receive similar scrutiny.

There are currently no vendor-published campaign-specific CVE-2026-119618 IOCs such as malicious IP addresses, domains, payload hashes, or attacker infrastructure because Apache and the reviewed sources have not reported exploitation in the wild. This makes configuration assessment and behavior-based monitoring more valuable than static indicator matching.

CVE-2026-119618 Mitigation

The primary remediation is to upgrade affected Apache HTTP Server installations to version 2.4.71 or apply the corrected security package supplied by the operating system vendor. Apache 2.4.71 was released on November 11, 2026 and contains the upstream fix.

Organizations should prioritize internet-facing Apache deployments with HTTP/2 enabled because these systems expose the vulnerable functionality directly to untrusted network traffic.

Administrators should take the following steps:

1. Inventory Apache HTTP Server deployments across production, development, cloud, and container environments.
2. Identify installations running Apache 2.4.55 through 2.4.70.
3. Verify whether mod_http2 is loaded.
4. Inspect global and virtual-host Protocols directives for h2 or h2c.
5. Upgrade upstream Apache deployments to 2.4.71 or later.
6. Apply distribution-specific packages when Apache is managed through Debian, Red Hat, Amazon Linux, or another operating system vendor.
7. Restart Apache after patching to ensure vulnerable worker processes are no longer running.
8. Verify the effective HTTP server configuration after remediation.
9. Review historical telemetry for suspicious activity on internet-facing systems that were exposed before patching.

Administrators should not assume that installing an operating system package with a version number below 2.4.71 means the system remains vulnerable. Vendors such as Red Hat backport security fixes into their own package versions, so the relevant distribution advisory should be treated as authoritative.

The official Apache advisory does not provide a workaround. However, organizations that cannot patch immediately can temporarily remove HTTP/2 from exposed configurations, eliminating access to the known vulnerable code path. Wiz recommends restricting the server to HTTP/1.1 until the update can be deployed.

For example:

Protocols http/1.1

Organizations applying this workaround should inspect all virtual hosts because a site-specific configuration can independently enable h2 or h2c.

Removing HTTP/2 can affect application performance and client behavior, so the change should be tested and treated as a temporary risk-reduction measure rather than a replacement for installing the security update.

The CVE-2026-119618 mitigation strategy should also include reducing unnecessary exposure. Administrative or internal Apache services that do not need direct internet connectivity should be restricted through network segmentation, load balancers, reverse proxies, firewall policies, or private addressing.

Organizations using standalone mod_h2 releases between 2.0.8 and 2.0.42 require particular attention. Apache identifies those releases as affected, while The Hacker News reported that no corrected standalone release had been published at the time of its November 12 report. Disabling HTTP/2 or migrating to an Apache HTTP Server package containing the upstream fix may therefore be necessary until an appropriate standalone update is available.

If suspicious activity is discovered, defenders should isolate the affected server where operationally feasible and preserve Apache access logs, error logs, system logs, process telemetry, network connections, and relevant memory or crash information.

Successful exploitation should be treated as potential server compromise rather than simply a service crash. Investigators should look for new files, webshells, altered application code, persistence mechanisms, stolen credentials, suspicious outbound traffic, and evidence of lateral movement.

Credentials accessible to the Apache process, including database passwords, API keys, cloud credentials, TLS private keys, or secrets stored in application configuration, should be reviewed and rotated when evidence suggests attacker-controlled code execution occurred.