TR-103 - Critical Remote Code Execution in Apache HTTP Server `mod_http2` (CVE-2026-119618)

Introduction

On 11 November 2026, the Apache Software Foundation disclosed CVE-2026-119618, a critical vulnerability in the Apache HTTP Server HTTP/2 module (mod_http2). A concurrency flaw can cause heap memory corruption and may allow an unauthenticated remote attacker to execute code with the privileges of the Apache web-server process.

The issue affects Apache HTTP Server 2.4.55 through 2.4.70 and was fixed upstream in 2.4.71, released on 11 November 2026. Separately distributed mod_h2 releases 2.0.8 through 2.0.42 are also listed as affected. Organisations using distributor-maintained packages should verify the presence of the security backport rather than rely only on the upstream version number.

CIRCL recommends prompt security updates for affected installations, with priority given to Internet-facing Apache servers that negotiate HTTP/2. Importantly, the vulnerable code path is not reachable merely because mod_http2 is installed or loaded: HTTP/2 must be enabled and reachable on the Apache service.

Technical details

The vulnerability is a race condition (CWE-362) in assign_headers() in mod_http2. During concurrent processing of HTTP/2 streams, a worker can modify a header table allocated for another execution context. This unsafe access to shared memory can corrupt the heap and lead to remote code execution or a server crash.

The upstream fix changes a write in modules/http2/h2_request.c from the shared request header table (req->headers) to the current request’s input header table (r->headers_in). Red Hat describes publicly demonstrated unauthenticated exploitation in a configuration where the affected HTTP/2 code path is enabled. This does not, by itself, establish exploitation in the wild.

Apache rates the issue Critical. Red Hat assigns CVSS v3.1 9.8 (Critical) for its general assessment, while noting that platform-specific build choices can affect exploitability. For example, Red Hat rates its RHEL 9 and 10 packages Important because their allocator implementation makes exploitation more difficult; Red Hat reports RHEL 8 and earlier as not affected. Apply the advisory specific to the deployed product and build.

Affected systems and vulnerability reachability

Exploitation requires a vulnerable mod_http2 build and an Apache endpoint that accepts HTTP/2. The Protocols directive determines whether HTTP/2 is available. h2 enables HTTP/2 over TLS; h2c enables cleartext HTTP/2.

Configuration	Vulnerability reachable?
`mod_http2` not loaded	No
`mod_http2` loaded, HTTP/1.1 only	No
`mod_http2` loaded, HTTP/2 enabled (`h2`)	Yes
`mod_http2` loaded, cleartext HTTP/2 enabled (`h2c`)	Yes
HTTP/2 enabled on only one virtual host	Potentially, through that virtual host

This table assumes an affected, unpatched version and a client able to reach the relevant Apache endpoint. Apache’s core default is Protocols http/1.1; loading mod_http2 does not automatically change that default. A virtual host with its own Protocols directive overrides the base server’s value. Consequently, checking only the global configuration can miss an HTTP/2-enabled virtual host.

Where a reverse proxy (such as haproxy), load balancer or CDN terminates HTTP/2 and forwards only HTTP/1.1 to Apache, the upstream client’s HTTP/2 session does not by itself make this Apache vulnerability reachable. Verify the actual protocol between each frontend and Apache; do not infer backend exposure from a public endpoint advertising HTTP/2.

Verification

Administrators can use the following commands as an initial configuration review (command and configuration paths may vary by distribution):

1
2
3
4
5
6
7
8
9


# Apache version and loaded modules
apachectl -v
apachectl -M | grep -i http2

# Identify configured virtual hosts
apachectl -S

# Locate explicit protocol settings, including virtual-host overrides
grep -RniE '^[[:space:]]*Protocols[[:space:]]+' /etc/apache2 /etc/httpd 2>/dev/null

For a reachable endpoint, test the negotiated protocol, preferably by connecting directly to the Apache service rather than through an intermediary:

1
2
3
4
5


# HTTP/2 over TLS (ALPN)
curl --http2 -sS -o /dev/null -w 'HTTP/%{http_version}\n' https://example.org/

# Cleartext HTTP/2 (direct h2c)
curl --http2-prior-knowledge -sS -o /dev/null -w 'HTTP/%{http_version}\n' http://example.org/

A response reporting HTTP/2 indicates that the tested endpoint accepted HTTP/2, but does not confirm that its Apache backend is vulnerable. Conversely, a negative test does not prove that all listening addresses, virtual hosts, ports or backend paths reject HTTP/2. Confirm the effective Apache configuration and the vendor’s patched-package status.

Mitigation and recommendations

Apply security updates

Upgrade to Apache HTTP Server 2.4.71 or later, or install a distributor-supplied build explicitly patched for CVE-2026-119618.
Update independently bundled or separately maintained mod_http2 components as directed by their vendor. Do not assume that a higher standalone module version exists without checking an actual vendor release or verified patch.
Restart affected Apache processes after updating and verify that the running processes use the corrected build.

Disable HTTP/2 temporarily if patching is delayed

If HTTP/2 is not required, restrict the supported protocols to HTTP/1.1:

1

Protocols http/1.1

Ensure that every relevant virtual host either inherits this restriction or explicitly applies it. Remove h2 and h2c from any overriding Protocols directives, test the configuration (apachectl -t), and reload or restart Apache. Verify the result from both the server configuration and the affected network paths. Unloading mod_http2 entirely is another possible temporary measure, provided no other functionality depends on it.

Disabling HTTP/2 prevents reachability of this particular vulnerability but does not remediate the vulnerable code. A security update remains the preferred permanent action.

Reduce exposure and monitor

Prioritise Internet-facing websites, APIs, shared-hosting environments and Apache instances behind frontends that forward HTTP/2 to the backend.
Where immediate patching or protocol changes are impossible, restrict access to trusted networks as a temporary risk-reduction measure.
Review unexpected Apache worker crashes, abnormal restarts, memory-corruption symptoms, suspicious child-process creation, unauthorised file changes and unexpected outbound connections. These are investigative leads, not confirmed indicators of compromise.
Preserve relevant logs and host evidence where exploitation is suspected; a successful software update does not remove persistence established before patching.

Guidance for organisations in Luxembourg

CIRCL recommends that organisations operating Apache HTTP Server inventory HTTP/2-enabled instances, determine whether the deployed mod_http2 build is affected, and patch exposed systems without delay. Teams should distinguish module presence from actual protocol reachability, particularly in environments with multiple virtual hosts or reverse proxies.

Organisations observing suspicious activity should follow their incident-response procedures and contact their relevant CSIRT, including CIRCL where applicable.

References

Classification of this document

TLP:CLEAR — Information may be distributed without restriction, subject to copyright controls.

Revision

Version 1.0 – TLP:CLEAR – Initial version – 12 November 2026.