HTTP2Reset (CVE-2026-119618): Pre-Auth Heap Corruption and RCE in Apache mod_http2

Executive Summary

CVE-2026-119618 is a critical race condition in Apache HTTP Server. It sits in mod_http2, the module that handles HTTP/2. The broken function is assign_headers(), which deals with request headers.

Here’s what goes wrong. A worker thread writes a Content-Length: 0 header into a table that belongs to the connection thread. It writes it through an allocator that has no lock. If both threads grab the same chunk of memory at the same moment, the heap of the child process is corrupted.

Apache 2.4.55 through 2.4.70 is affected. The fix is in 2.4.71, released on November 11, 2026.

The attacker needs no credentials. One crafted HTTP/2 request reaches the bug. So any Apache server in that range that speaks HTTP/2 is exposed. That means h2 over TLS, or h2c in cleartext. Apache rates the flaw critical. Red Hat scores it CVSS 9.8. Red Hat also says a worker thread that corrupts connection-thread memory can lead to full control of the server process.

The bug class is well known. The problem is how many servers it reaches. Apache runs about a quarter of all websites. HTTP/2 is used on more than a third. And on Debian and Ubuntu, one a2enmod http2 turns on both h2 and cleartext h2c for every virtual host.

Anthropic’s AI-based OSS Scanner reported the bug to Apache on October 26, 2026. Google Cloud Vulnerability Research sent its own report eight days later. This is the second serious memory-safety flaw in the same module in six months. The first was CVE-2026-23918 in May. The standalone build of the module now has no maintainer, so nobody can ship a separate fix for it.

TL;DR for Engineering Teams

• What it is: a pre-auth race condition (CWE-362) in Apache mod_http2 assign_headers(). Apache: critical. Red Hat: CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). CVE-2026-119618.
• Where it bites: Apache HTTP Server 2.4.55 to 2.4.70, and standalone mod_h2 2.0.8 to 2.0.42. Only when HTTP/2 is negotiated. A server in range that never speaks h2 or h2c can’t be reached this way.
• Why it matters: no auth, one request. Public labs reproduce heap corruption and worker crashes under sanitizers. One vendor lab got attacker-controlled bytes into a pointer the server dereferences. No confirmed exploitation in the wild. Not in CISA KEV as of November 10, 2026.
• Patch status: fixed in Apache 2.4.71. RHEL 9 and 10 are patched. Debian stable, Ubuntu and Amazon Linux had no fix on November 12, 2026.
• What to do now: upgrade to 2.4.71 or the vendor-fixed package, then restart httpd. No patch yet? Set Protocols http/1.1 server-wide and in every virtual host, then reload.

Vulnerability Overview

Technical Anatomy

Root cause

HTTP/2 lets a client send many requests over one connection. In mod_http2, each request stream runs on its own worker thread. Each worker has its own memory pool. The connection itself is run by a separate connection thread.

The connection thread’s allocator is lock-free. No mutex guards its free list. That’s only safe as long as worker threads never touch memory owned by the connection.

assign_headers() breaks that rule for one specific request shape:

• the request has a Content-Type header
• it has no Content-Length
• it has no body, because the client already set END_STREAM on the HEADERS frame

For that request, the code adds a Content-Length: 0 header. In 2.4.55 through 2.4.70, it writes that header into req->headers. That’s the stream’s shared header table. It should go into r->headers_in, the copy that belongs to the single request.

If the shared table is already full, the write needs a new node. That node comes from the connection thread’s lock-free allocator. If the connection thread is allocating or freeing on the same list at that moment, both threads take the same node. The heap is corrupted.

The upstream fix is one line. It was cherry-picked from trunk in commit 824beab:

diff

- apr_table_setn(req->headers, "Content-Length", "0");
+ apr_table_setn(r->headers_in, "Content-Length", "0");

The patch moves the write to the request’s private table. That’s the whole fix. Because it’s so small, defenders should treat the root cause as real and well understood. That holds even while the exploitation question is still open.

Exploit path

1. Entry point. An unauthenticated client opens an HTTP/2 connection to an Apache server in the affected range. It can be h2 over TLS or h2c in cleartext. No login, header or cookie is needed.
2. Trigger. The client sends a request with no body. It has a Content-Type header, no Content-Length, and END_STREAM set on the HEADERS frame. It also carries enough extra headers to fill the stream’s header table, so the added header forces a fresh allocation. Public reproductions used about 80 headers. They tuned filler sizes so the stream pool node had only a few hundred bytes free. That’s where corruption was most reliable. Bursts of streams keep the connection allocator’s free list short and raise the odds of a collision.
3. Impact. The worker thread and the connection thread take the same memory node. The connection thread then follows a corrupted pointer. In one vendor lab, that pointer held 0x4141414141414141. Those are filler bytes the attacker sent. So attacker-controlled data does reach a dereferenced pointer. The most common result is a worker crash. That drops every in-flight request on the connection. If an attacker can steer the corruption into a function pointer, code runs as the httpd worker user. That’s www-data on Debian and Ubuntu, and apache on RHEL. It’s enough to read site code, config and stored secrets. In Kubernetes, it’s enough to reach the pod service-account token and the cloud metadata identity.

One limit matters for weaponization. mod_http2 accepts only visible ASCII in header values. So any binary payload bytes would have to come in request bodies, not headers. That makes a working RCE chain harder. It’s part of why public evidence stops at corruption and crashes.

Affected Versions

Red Hat rates the flaw Important on RHEL 9 and 10, not Critical. Those packages give each HTTP/2 stream its own allocator, which makes exploitation harder. Upstream builds don’t get that benefit.

Exposure Analysis

Public web stats give an upper bound. They don’t give an exact count.

W3Techs ranks Apache third among web servers, at 23.7 percent of sites. HTTP/2 is negotiated on 35.1 percent of all websites and 51.3 percent of the top million.

Many of those HTTP/2 sessions end at a CDN, not at an Apache origin. So the real number of vulnerable origins that speak HTTP/2 is lower than any version-only estimate. At the time of writing, no Shodan or Censys count for this CVE was published. Treat any internet-wide number you see as unverified.

[IMAGE 2: “Am I exposed?” decision flow] Place here, at the end of “Exposure Analysis” and before “Real-World Impact”. Alt text: Decision flow for CVE-2026-119618 exposure: Apache version 2.4.55 to 2.4.70, HTTP/2 negotiated via h2 or h2c, and no proxy downgrade to HTTP/1.1 means the server is reachable.

Real-World Impact

Today, the proven outcome is denial of service. Public reproductions crash Apache worker processes on demand. Every in-flight request on that connection is dropped. Repeat the trigger and the outage keeps going. That alone is a reason to act fast on internet-facing hosts.

Remote code execution is credible, but not proven in public.

Apache’s advisory says the corruption can lead to code execution. That’s the standard call for this bug class. Red Hat goes further. It says public research has shown a reliable exploit against a default-configured server. But neither Red Hat nor anyone else names or links that research, and we found no public exploit that matches.

No in-the-wild exploitation has been reported. The public repos support the cautious view. The strongest proof of concept reproduces heap corruption and sanitizer crashes on instrumented builds. It says clearly that it doesn’t deliver a payload. It also runs in a non-default configuration.

For prioritization, treat RCE as plausible, because attacker data reaches a dereferenced pointer. Just keep in mind that no ready-made exploit is public, and the ASCII-only header limit makes a full chain harder.

If an attacker does get code execution, realistic next steps are:

• pulling secrets from config and runtime memory
• dropping a web shell into the document root
• in Kubernetes, moving through the pod service-account token and cloud metadata identity into the wider environment

Detection Guidance

Confirm HTTP/2 is actually negotiated

The version range is needed, but it’s not enough. A server in range that never speaks h2 or h2c can’t be reached through this bug.

Check the loaded module and every Protocols directive. That includes the ones inside virtual hosts and included files:

bash

apachectl -v                                              # version
apachectl -M 2>/dev/null | grep -i http2                  # is mod_http2 loaded
grep -rniE '^\s*Protocols' /etc/apache2 /etc/httpd 2>/dev/null
curl -sI --http2 https://host/ | head -1                  # HTTP/2 200 means h2
curl -sI --http2-prior-knowledge http://127.0.0.1/ | head -1   # tests h2c

A Protocols line inside a virtual host overrides the global setting. Read every match, not just the first one.

Account for proxies

The attack needs an HTTP/2 connection to Apache itself.

If a CDN or load balancer ends the client’s HTTP/2 and talks HTTP/1.1 to the origin, mod_http2 is never reached. You lose that protection if the proxy uses HTTP/2 to the origin. You also lose it if the origin port can be reached directly.

Test from outside, and test on the host with curl --resolve host:443:127.0.0.1.

Log indicators

There are no confirmed attacker IOCs, because nobody has seen exploitation. The signals below come from public labs, not from real attacks.

What to hunt for:

• clusters of Apache child processes exiting on a segmentation fault or abort, linked to HTTP/2 connections
• general protection faults inside libapr and assertion aborts inside mod_http2
• HTTP/2 requests with about 80 headers, a Content-Type header, no Content-Length, and END_STREAM on the HEADERS frame, arriving in bursts across many streams on a few connections

After a suspected hit, look for:

• processes spawned by the httpd or apache2 user
• new files in document roots
• the httpd user reading the Kubernetes service-account token path or calling the cloud metadata endpoint

Scanner coverage

At publication, NVD had no CPE or CVSS metrics. Scanners that depend on NVD may lag or show N/A severity.

Use vendor feeds for package truth: Red Hat OVAL and CSAF, the Debian security tracker, and Amazon ALAS.

SBOM and SCA tools should match the mod_http2 module version in the 2.0.8 to 2.0.42 range, not just the httpd version. That’s how backported builds like Ubuntu 22.04 get caught. For containers, rebuild images. Don’t rely on scanning a running banner.

Verification steps for teams

1. List every Apache host. Record its version and loaded modules.
2. For each host, test whether h2 and h2c are actually negotiated, from outside and locally.
3. Check the installed package release string (rpm -q mod_http2, dpkg -l apache2-bin), not the Server: banner. Fixed packages keep upstream-looking version numbers.
4. Run external attack surface discovery for hosts that advertise h2 via ALPN on 443 or accept h2c on 80. Put the ones with Apache banners first.
5. Cross-check SBOMs for the mod_http2 module version. This catches backported builds that version-only scans miss.

Remediation Guidance

Immediate actions

Upgrade to the fixed build and restart. Don’t just reload, or the old binary keeps running.

1. RHEL 9 and 10: run dnf update mod_http2, restart httpd, and check rpm -q mod_http2 against the package version in the RHSA. RHEL 8 and earlier need nothing.
2. Upstream builds and containers: move to Apache 2.4.71 or the httpd:2.4.71 image. Then check with apachectl -v that the running binary is the new one.
3. Standalone mod_h2 users: there is no newer standalone release. The project was archived on June 9, 2026. Move to the mod_http2 bundled with 2.4.71, or turn off HTTP/2.

The same 2.4.71 release fixes two related flaws that turning off HTTP/2 won’t fix: CVE-2026-106023 in mod_md (rated important) and CVE-2026-109163 in mod_vhost_alias (rated low). Patching is the only complete fix.

Temporary mitigations if patching is delayed

Debian stable, Ubuntu, Amazon Linux, AlmaLinux, Rocky, cPanel and JBoss Core Services may not have a fix yet. On those hosts, turn off HTTP/2 where you don’t need it:

1. Set Protocols http/1.1 globally and remove h2 and h2c from every virtual host. On Debian and Ubuntu, you can run a2dismod http2 instead.
2. Run apachectl configtest, reload, and run the curl checks again. Confirm h2 and h2c no longer negotiate.
3. Browsers fall back to HTTP/1.1 on their own. Users behind a CDN keep HTTP/2 at the edge. So the cost for users is small.

Apache doesn’t publish a workaround. The public lab’s mitigated container shows this mitigation works. Turn HTTP/2 back on only after the patched package is confirmed on the host.

In Kubernetes, limit the blast radius:

• set automountServiceAccountToken: false for front-end pods
• give each workload a least-privilege cloud identity
• use egress NetworkPolicies to block the API server and metadata endpoints

Phoenix Security Recommendations

This advisory is moving fast and the facts are still contested. Phoenix Security turns it into a backlog with owners.

Contextual deduplication pulls CVE-2026-119618 findings from SCA, container and external attack surface scanners into one item per affected service. Your team doesn’t triage the same host three times from three tools.

Reachability analysis separates Apache instances that actually speak HTTP/2 from those that only sit in the version range. That’s the line that decides if this flaw is reachable at all. It also catches the backport trap, where a 2.4.52 banner hides an in-range mod_http2 module.

Attack surface management finds the internet-exposed services that advertise h2 and h2c. Those go to the front of the queue.

Remediation campaigns close the loop. Create a campaign scoped to the affected module. Assign owners by service. Track the upgrade to 2.4.71 or the temporary Protocols http/1.1 mitigation. Verify runtime exposure once the fix lands.

Vulnerability ownership attribution maps each finding to the right team automatically. No in-range, internet-facing Apache host is left without a named owner while the exploitation question stays open.

Protect yourself with the latest threat intelligence, get free access to Phoenix Blue Today

External References

1. Apache HTTP Server security advisory, vulnerabilities_24
2. oss-security disclosure: CVE-2026-119618, mod_http2 heap corruption and RCE in assign_headers
3. Apache httpd fix commit 824beab (assign_headers update table)
4. Red Hat CVE page: CVE-2026-119618
5. The Hacker News: Critical Apache HTTP/2 flaw coverage, November 2026
6. Help Net Security: Anthropic OSS Scanner announcement
7. oss-security: prior mod_http2 flaw CVE-2026-23918, May 2026
8. Debian security tracker: CVE-2026-119618 (sid fixed in apache2 2.4.71-1)
9. Amazon Linux security center: CVE-2026-119618 (pending)