Critical Apache HTTP/2 RCE Flaw Lets Unauthenticated Attackers Take Full Control of the Server

Summary

Vulnerability Details

Technical Information

Related Issues and Disclosure Timeline

1. 26 October 2026Anthropic's OSS Scanner reports ANT-2026-MAPKT6MZ.
2. 3 November 2026Google Cloud researchers Anthony Weems and Simon Scannell report the issue.
3. 11 November 2026Apache releases the fix in HTTP Server 2.4.71.

The same release addresses CVE-2026-106023, a mod_md null-pointer dereference rated Important, and CVE-2026-109163, a one-byte mod_vhost_alias stack overwrite rated Low.

Impact

• An unauthenticated client may be able to run code in the affected server process.
• Files, application credentials, and backend services accessible to that process may be exposed or modified.
• Memory corruption may crash workers and interrupt requests.

The impact depends on the permissions and resources available to the compromised server process. On Unix systems, Apache's User directive controls the account used to handle requests. Root access is not an established outcome of this vulnerability alone.

Affected Products and Versions

• Apache HTTP Server 2.4.55 through 2.4.70
• Standalone mod_h2 releases on GitHub, versions 2.0.8 through 2.0.42

Check three conditions together: an affected or unpatched module, HTTP/2 enabled on a listener or virtual host, and a network path that lets a client reach that listener.

Loading mod_http2 alone does not establish exposure. Apache requires HTTP/2 to be enabled with the Protocols directive. Both h2 (HTTP/2 over TLS) and h2c (cleartext HTTP/2) matter. These are examples of configurations to review, not mitigation settings:

# HTTP/2 over TLS
Protocols h2 http/1.1

# HTTP/2 over TLS and cleartext
Protocols h2 h2c http/1.1

The directive can apply globally or within a virtual host. Review included configuration files and overrides as well as the main configuration.

For proxy and CDN deployments, assess each connection separately. Browser-to-edge HTTP/2 does not establish that the edge-to-Apache connection uses HTTP/2. Conversely, an origin reachable directly or over an internal HTTP/2 path still requires assessment. A public endpoint check describes only the listener that answered it.

MITRE ATT&CK Mapping

Mitigation and Recommendations

Fixed Releases

Confirm the full installed package version against the supplier's advisory. Distribution fixes may be backported without changing the upstream version shown by httpd -v.

Check the Installed Module and HTTP/2 Configuration

Use the Apache control command associated with the running service. On some distributions, it is named apache2ctl rather than apachectl.

apachectl -v
apachectl -M
apachectl -S

These commands report the server version, loaded modules, and virtual hosts. Look for http2_module, then inspect Protocols settings in the active configuration and included virtual hosts for h2 or h2c. A loaded module alone does not confirm HTTP/2 exposure. These checks also do not establish whether a vendor security patch is installed.

To check TLS protocol negotiation, send a normal request using an HTTP/2-capable curl build:

curl --http2 --silent --show-error --output /dev/null --write-out '%{http_version}\n' https://www.example.com/

Replace the hostname with the endpoint being assessed. A result of 2 confirms HTTP/2 on that connection, not vulnerability. Check origin servers separately when a proxy or CDN answers the request. This command does not test cleartext h2c. The command options are documented by Apache and curl.

Install the Fix and Replace Running Workers

1. Select the correct update. Use Apache 2.4.71 or the vendor-fixed packages for your supported release stream.
2. Validate compatibility. Check application routing, TLS, authentication, proxy behavior, and HTTP/2-dependent clients. Run apachectl -t to check configuration syntax before restarting.
3. Deploy across the fleet. Update every instance, including container images and deployment templates that could recreate an affected server.
4. Restart using the service's supported procedure. Confirm that old processes using the vulnerable module have exited. Replacing a package on disk does not replace code already loaded in memory.
5. Verify and record the result. Confirm package fix status, service health, expected protocol negotiation, and coverage of all nodes.

Apache documents that a graceful restart preserves existing connections. Account for that behavior when deciding whether vulnerable workers have fully retired. The apachectl documentation explains the differences between restart procedures.

If Patching Must Wait, Disable HTTP/2

If an update cannot be installed immediately, configure affected listeners to offer only HTTP/1.1. This recommendation follows the documented HTTP/2 exposure requirement. Apache does not publish a separate workaround in its CVE entry.

Protocols http/1.1

Remove h2 and h2c from every applicable server and virtual-host setting, validate with apachectl -t, and apply the configuration through the supported service procedure. Ensure existing HTTP/2 connections and affected workers have ended, then repeat endpoint checks. Confirm that clients requiring HTTP/2 remain operational or have an alternative path.

Track this as a temporary exception with an owner and a patch deadline. Network restrictions can reduce reachability, but they do not correct the memory-safety flaw.