On November 11, 2026, Apache released a security update addressing CVE-2026-119618, a critical vulnerability in mod_http2, the module that handles HTTP/2 connections in Apache HTTP Server.

The flaw can corrupt server memory and potentially allow a remote attacker to execute code without authentication, with the privileges of the Apache process. It affects upstream versions 2.4.55 through 2.4.70 and is fixed in 2.4.71.

For teams running Apache, the first question is whether their servers actually accept HTTP/2. Having an affected version installed is part of the picture, but the enabled modules, virtual-host configuration, and distribution packages all matter.

Here is what to check and how to respond.

Last reviewed: November 12, 2026. Distribution fixes and threat intelligence may change after publication.

CVE-2026-119618 at a glance

These version ranges and the upstream fix are documented in Apache’s security advisory.

How HTTP/2 request handling can lead to code execution

HTTP/2 allows several requests to travel over the same connection at once. Apache handles that concurrent work across different execution contexts, which makes correct memory ownership essential.

The problem occurs in assign_headers(): a worker can modify shared memory belonging to the connection thread. That unsafe interaction can corrupt the heap and potentially give an attacker control over the server process.

The consequences depend on what that process can access. Application files, credentials, and backend services may all become relevant when assessing the impact. Remote code execution in Apache does not automatically mean root access, but it can still provide a serious foothold.

Apache credits Anthropic’s OSS Scanner and Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research with reporting the issue.

Which Apache deployments are exposed?

The key distinction is whether HTTP/2 reaches the vulnerable Apache instance. Loading mod_http2 alone does not make the vulnerability reachable.

Apache’s upstream default is Protocols http/1.1. HTTP/2 becomes available when the configuration enables h2 for TLS connections or h2c for cleartext connections. Distribution packages, hosting tools, or an administrator’s configuration may enable either.

This is worth checking at the virtual-host level: a site can override the main server’s protocol settings, so reviewing only the global configuration can miss an exposed endpoint.

Distribution builds also deserve a closer look. Red Hat’s assessment identifies RHEL 8 and earlier as unaffected because the vulnerable code is absent. RHEL 9 and 10 are affected, but rated Important rather than Critical: their module packages use separate allocators per HTTP/2 stream, making exploitation substantially harder.

That difference illustrates why an upstream version number is a starting point, rather than a complete exposure assessment.

Check the server that actually handles the connection

A useful first pass is to identify the Apache version, loaded modules, and configured virtual hosts:

apachectl -v
apachectl -M
apachectl -S

Depending on your distribution, the wrapper may be named apache2ctl.

Look for http2_module, then review the active configuration and included files for Protocols settings containing h2 or h2c. Check the installed package revision against your distributor’s advisory too, including the module package where it is maintained separately. A backported fix may leave the upstream version number unchanged.

If Apache sits behind a CDN, load balancer, or reverse proxy, check the connection to the origin separately. A browser may use HTTP/2 to reach the frontend while the frontend communicates with Apache over HTTP/1.1.

The reverse is also worth investigating: an origin may expose another listener that clients can reach directly. What matters is which protocols the Apache service accepts along each reachable path.

Patch the running deployment

For upstream installations, the fix is Apache HTTP Server 2.4.71 or a later fixed release. For distribution packages, use the security update provided for your specific release; the Debian security tracker and your vendor’s advisory provide the relevant package status.

After updating, restart Apache through your platform’s service manager so the corrected code is loaded. In container environments, rebuild affected images and replace running instances: changing an image tag does not update containers already running.

There is an additional detail for separately installed modules. The standalone icing/mod_h2 repository is archived, with 2.0.42 still listed as its latest release at the time of review. There is no newer patched release there to recommend.

For those installations, move to the fixed module bundled with httpd 2.4.71 or obtain a verified patched package from your supplier. Check which module Apache actually loads, especially if an older copy was installed outside the package manager.

If patching needs more time

Disabling HTTP/2 temporarily can remove access to the vulnerable code path while you prepare the update. This is also recommended in CIRCL’s technical report TR-103 when patching is delayed and HTTP/2 is not required.

Set the relevant server and virtual hosts to:

Protocols http/1.1

Check for overrides that still enable h2 or h2c, then validate the configuration:

apachectl configtest

Apply the change using your platform’s supported restart procedure, test your application, and verify that the affected listeners no longer accept HTTP/2.

This is a temporary mitigation: the vulnerable code remains installed, so the security update should still follow.

Follow Apache vulnerabilities with OpenCVE

Once the immediate response is underway, keeping track of new information becomes part of the work: distribution fixes may arrive at different times, and vulnerability records can gain additional details after disclosure.

OpenCVE helps your team monitor the vendors and products in your stack, follow CVE updates, and receive notifications through automations. You can also assign vulnerabilities and track their status as your team reviews and addresses them.