CVE-2026-119618: Apache’s HTTP/2 Race and the Running Fix

Apache HTTP Server serves websites and applications, sometimes directly and sometimes behind a load balancer or reverse proxy. Its HTTP/2 module, mod_http2, handles a protocol that lets several requests share one connection. On November 11, 2026, Apache released HTTP Server 2.4.71 to fix CVE-2026-119618, a critical flaw in that module. Apache’s security advisory identifies HTTP Server 2.4.55–2.4.70 and separately distributed GitHub mod_h2 releases 2.0.8–2.0.42 as affected.

The flaw is a race condition: concurrent work accesses shared data without sufficient coordination. In this case, header handling in assign_headers() can corrupt heap memory—the memory a process allocates while running—and lead to remote code execution. Successful exploitation could let an attacker run code with the web-server process’s privileges. The affected component matters: finding an Apache package alone does not establish whether requests can reach its HTTP/2 handling. Apache’s original disclosure names the module and the memory-corruption risk.

Apache credits Anthropic’s OSS Scanner, which reported the issue on October 26, and Google Cloud researchers Anthony Weems and Simon Scannell, whose report arrived on November 3. Apache published the fix and release on November 11. Merav Bar’s Wiz report that day subsequently explained the risk and said there were no reported cases of exploitation at publication. That is a dated assessment. The vulnerability disclosure establishes affected code and a possible consequence; it does not establish that every affected installation was attacked or provide a reliable log signature for exploitation.

How to check your Apache deployment

These checks apply if you operate Apache directly, inside a container or behind another server. They help separate affected code, reachable HTTP/2 configuration, an installed fix and replacement of the running processes. They do not settle whether an attacker previously used the flaw.

Identify the serving installation

Start with the service definition or container configuration that launches Apache. Record its executable, startup arguments, configuration file and image or package identity. Repeat this for every serving instance, including replicas still receiving traffic during a rollout.

Use that installation’s Apache wrapper for inspection. For example, where apachectl is the wrapper used by the service:

apachectl -v
apachectl -V
apachectl -M
apachectl -S

These are inspection options, with no start, stop or reload action. Use the same environment and relevant configuration arguments as the service. A different wrapper, -f configuration path or startup definition can inspect a different installation.

The official command reference defines the results:

• -v prints the invoked executable’s version.
• -V adds build parameters, which help locate its default configuration.
• -M lists static and shared modules loaded by the inspection process. Look for http2_module.
• -S shows parsed virtual-host settings and helps locate the relevant configuration files.

These commands run a separate inspection process. They do not report which library bytes the existing daemon has loaded. Nor does -S print a complete effective protocol configuration. Keep package inventory and live-process evidence separate.

Check where HTTP/2 reaches Apache

Inspect the main configuration, its included files and each reachable virtual host. Apache calls HTTP/2 over TLS h2; its supported cleartext variant is h2c. Both belong in the review. Apache’s HTTP/2 guide explains module loading and protocol activation.

A base-server setting can be overridden. This illustrative fragment shows the problem; it is not a complete TLS configuration:

Protocols http/1.1

<VirtualHost *:443>
    ServerName orders.example.net
    Protocols h2 http/1.1
    # Existing TLS and application directives remain here.
</VirtualHost>

The virtual host still permits h2. Its own Protocols list replaces the base-server list, as the directive documentation specifies.

Trace both sides of any proxy. A browser negotiating HTTP/2 with a CDN does not establish the protocol used between that CDN and Apache. Conversely, an HTTP/1.1 public endpoint does not rule out another listener or internal route that reaches Apache over HTTP/2.

If patching must wait, temporarily restricting reachable Apache virtual hosts to http/1.1 can remove the HTTP/2 request path. Check overrides and included files before applying that change. Validate the resulting configuration, apply it through the deployment’s normal change procedure, and verify the actual listeners afterward. Editing a file alone changes nothing in the running service. Protocol restriction is temporary mitigation; retain the update task.

Verify the installed fix and running processes

For the upstream HTTP Server release, 2.4.71 contains the fix. Distribution packages may carry a backported fix under an older upstream version number. Require a vendor advisory that explicitly covers this CVE and the installed package release.

For standalone mod_h2, obtain explicit confirmation for the module release you deploy. The affected range ends at 2.0.42, but that boundary alone is not confirmation of a particular fixed release.

Follow your package or image vendor’s replacement procedure. Record the deployment revision, artifact identity, replacement time and process evidence. A successful syntax check establishes that configuration parsing succeeded. A successful request establishes that one request worked. Neither proves that the running module contains the fix.

Review retained restart and request evidence

Preserve available error, access and service-manager logs around remediation. If the destination is unclear, find Apache’s active error log before assuming a familiar path contains the relevant events.

The following is a synthetic UTC timeline, written as normalized investigation notes. It is not native Apache output or a detection signature:

2026-11-12T13:20:00Z host=web-07 source=deployment event=fixed_package_installed
2026-11-12T13:24:10Z host=web-07 source=service_manager event=restart_completed
2026-11-12T13:24:15Z host=web-07 source=access_log method=GET path=/health status=200
2026-11-12T13:25:02Z host=web-07 source=access_log method=GET path=/catalog status=200

This sequence records installation, a reported restart and later request outcomes. It still needs artifact and process checks to establish that the serving instance uses fixed code. A restart record alone does not identify every loaded module, and two successful requests do not establish complete recovery.

If these events were already collected in Fluxtail, use its documented search and filters to inspect the remediation window:

1. Select the stream containing the relevant Apache or host events and set a bounded time range around replacement.
2. Inspect a known raw event to confirm the host and service field values. Add those exact filters only when the fields are populated.
3. Search a stable fragment from an actual restart message. Then clear the message search to examine nearby request outcomes and failures.
4. Check other relevant streams if service-manager and access events are collected separately.

Fluxtail’s live log viewer can help follow subsequent collected events. Historical review depends on collection and retention already being in place. An empty search means no retained row matches all active filters; it cannot establish that exploitation did not occur.

For unexplained crashes or suspicious activity, extend the investigation to available process, file-change, authentication and network evidence. A crash is a symptom with several possible causes. Keep the investigation bounded by time and host, and preserve raw records before drawing conclusions. The guide to reading logs during incidents covers that correlation process.

Finish with separate records for the fix, process replacement and investigation findings. That makes it clear which instances have been remediated, which checks remain open and what the available evidence actually shows.