- What happened: Apache httpd 2.4.71 fixes CVE-2026-119618, a critical race in mod_http2 that can lead to remote code execution.
- Who is affected: Servers on 2.4.55 through 2.4.70 that actually speak HTTP/2 (h2 or h2c).
- What to do now: Install 2.4.71 or your distro’s patched package. If you can’t yet, switch Protocols to http/1.1.
- Interview angle: Race conditions, heap corruption, HTTP/2 multiplexing and why version strings lie on patched distros.
CVE-2026-119618 is a critical flaw in Apache HTTP Server’s mod_http2. Concurrent HTTP/2 streams can hit improperly synchronised shared memory in assign_headers(), corrupting the heap. Red Hat scores it 9.8. Upgrade to 2.4.71 or a backported package, and disable HTTP/2 until you do.
A race condition is a bug where the result depends on the timing of two or more threads touching the same data. When that data is heap memory and nothing serialises access, one thread can overwrite structures another thread is still using.
The fix landed on 11 November 2026 with Apache HTTP Server 2.4.71. The Apache advisory rates it critical. Below: who is exposed, how it works, a checklist, and the interview questions it maps to. We also ran the checks on Ubuntu 24.04 in our sandbox, and the result is a warning about version-based scanning.
What changed in CVE-2026-119618 and who is affected?
Apache published three fixes in 2.4.71. This is the critical one.
| Item | Detail |
|---|---|
| Component | mod_http2, function assign_headers() (ASF advisory) |
| Weakness | Concurrent execution using shared resource with improper synchronisation (CWE-362) (Red Hat) |
| Affected httpd | 2.4.55 through 2.4.70 |
| Affected standalone mod_h2 | 2.0.8 through 2.0.42 |
| Fixed in | httpd 2.4.71, released 2026-11-11 |
| Severity | ASF: critical. Red Hat: CVSS 3.1 base 9.8, rated Important on RHEL 9 and 10 |
| Not affected | RHEL 8 and earlier; any server serving only HTTP/1.1 |
| Reported | 2026-10-26 by Anthropic’s OSS Scanner, and 2026-11-03 by Google Cloud Vulnerability Research |
The release also fixes CVE-2026-106023 (important, mod_md crash) and CVE-2026-109163 (low, mod_vhost_alias).
Distribution status is uneven. Debian’s tracker lists 2.4.71-1 as fixed in sid. The CSA research note warns that backported packages may never show “2.4.71” in their version string. Wiz reports that 64% of cloud environments have resources running vulnerable versions, though that figure ignores whether HTTP/2 is switched on.
How does it work?
HTTP/2 multiplexes many streams over one TCP connection. mod_http2 hands stream work to worker threads while a connection thread manages the socket. Red Hat describes the flaw like this:
- A client opens an HTTP/2 connection and sends several streams at once.
- Worker threads process those streams in parallel.
- In assign_headers(), a worker thread writes into memory owned by the connection thread through a shared, lock-free allocator.
- Nothing serialises that access, so two threads can modify the same heap region at once.
- The heap gets corrupted. With effort, heap corruption can be steered into code running as the httpd user.
Red Hat lowers the rating on RHEL 9 and 10 because their packages give each HTTP/2 stream a separate allocator, which makes exploitation much harder.
The safe pattern: memory owned by one thread is written only by that thread, or under a lock.
// Illustrative C-style pseudocode, not httpd source
// Unsafe: worker writes into the connection's pool directly
copy_headers(conn->pool, stream->headers);
// Safer: worker allocates from its own stream pool,
// then the owner thread takes the result
copy_headers(stream->pool, stream->headers);
hand_off_to_connection(stream);What should developers do right now?
This checklist combines ASF, Red Hat and CSA guidance. We tested it on Ubuntu 24.04.
- Find servers that speak HTTP/2. Check
apachectl -M | grep http2and grep enabled config forProtocols. The Apache HTTP/2 guide shows h2 is enabled through that directive. - Check the package, not only the banner. Look for the CVE in the package changelog or vendor errata.
- Patch. Install httpd 2.4.71 or your distro’s fixed build, then restart Apache.
- If no patch exists yet, drop HTTP/2. Set
Protocols http/1.1everywhere Protocols appears, or unload mod_http2. CSA advises first confirming no gRPC back ends or h2c upgrades depend on it. - Verify with a live probe. Confirm the server now answers over HTTP/1.1.
- Rebuild images. Container images pinned to old httpd digests stay vulnerable until rebuilt.
What we saw when we ran it
We installed apache2 from Ubuntu 24.04’s archive in our sandbox on 13 November 2026 and ran the read-only script below. Raw output:
== Version string
Server version: Apache/2.4.58 (Ubuntu)
== Package
apache2 2.4.58-1ubuntu8.19
== Fix in changelog?
YES: package changelog lists CVE-2026-119618
== mod_http2 loaded?
not loaded
== Protocols directives
none (default: http/1.1 only)Two findings matter. First, the banner says 2.4.58, inside the affected range. A version-only scanner would flag this server, yet the changelog shows the fix is applied. Second, HTTP/2 was off by default. The Protocols h2 h2c http/1.1 line sits unused in mods-available/http2.conf until a2enmod http2.
After a2enmod http2 and a start, curl --http2 http://127.0.0.1/ reported HTTP version 2. After changing Protocols to http/1.1 and restarting, the same command reported 1.1. A prior-knowledge h2c request then failed with curl exit code 56. That is the workaround behaving as intended.
The script, to adapt for your fleet:
#!/usr/bin/env bash
# Read-only exposure check (Debian/Ubuntu layout)
CTL=$(command -v apache2ctl || command -v apachectl)
$CTL -v | head -1
dpkg-query -W -f='${Package} ${Version}\n' apache2
zgrep -q "CVE-2026-119618" /usr/share/doc/apache2/changelog.Debian.gz \
&& echo "fix listed in changelog" || echo "fix NOT listed"
$CTL -M 2>/dev/null | grep -i http2 || echo "mod_http2 not loaded"
grep -RHiE '^\s*Protocols\s' /etc/apache2/apache2.conf /etc/apache2/*-enabled/ \
|| echo "no Protocols lines (default http/1.1)"On RHEL-family hosts, use rpm -q --changelog httpd mod_http2 instead of the Debian changelog path.
Interview questions this update prepares you for
1. What is the difference between a race condition and a data race?
A data race is a specific event: two threads access the same memory at the same time, at least one writes, and nothing orders the accesses. A race condition is broader. It is any bug where correctness depends on timing, even if every individual access is synchronised, such as a check-then-act gap. Data races in C or C++ are undefined behaviour and can corrupt memory. Race conditions in safe languages usually produce wrong results rather than corruption. The Apache bug is the first kind: unsynchronised writes to shared heap memory.
Follow-up they may ask: How would you detect one? (ThreadSanitizer, stress tests, code review of ownership.)
2. Why can heap corruption lead to remote code execution?
Allocators keep metadata next to user data, and programs store pointers and lengths on the heap. If an attacker can influence which bytes land where, they may overwrite a pointer the program later follows. That turns a memory bug into control of execution. ASLR, hardened allocators and control-flow integrity make this harder, which is why vendors can rate the same bug differently. Red Hat’s per-stream allocator is one such design choice.
Follow-up they may ask: Name two exploit mitigations and what each one blocks.
3. How does HTTP/2 multiplexing change a server’s concurrency model?
HTTP/1.1 effectively handles one request at a time per connection, so a connection maps cleanly to one worker. HTTP/2 carries many independent streams on one connection, processed in parallel. Several threads now touch state tied to one connection, and that shared state is where synchronisation bugs appear. It is also why Apache’s docs say prefork handles only one request at a time per HTTP/2 connection.
Follow-up they may ask: What is head-of-line blocking, and does HTTP/2 remove it fully?
4. Why can’t you trust a server’s version banner during incident response?
Enterprise distributions backport security fixes into older upstream versions to keep behaviour stable. The banner keeps the original number while the package revision changes. Our Ubuntu test showed 2.4.58 with the fix applied. The reverse happens too: a custom build can report a new version yet miss a patch. Reliable checks use package changelogs, vendor errata IDs or SBOM data.
Follow-up they may ask: How would you build a fleet-wide inventory you can trust?
The NexGismo verdict: My recommendation is to treat this as a same-week patch for any public Apache that speaks HTTP/2. Don’t let a version-only scanner decide; our test showed it misreads a patched Ubuntu host. Turn off modules you do not use; the safest HTTP/2 code is the code that never loads.
- CVE-2026-119618 is a critical race in Apache mod_http2’s assign_headers() that can lead to RCE.
- Affected upstream versions are 2.4.55 through 2.4.70; 2.4.71 fixes it.
- Servers that serve only HTTP/1.1 are not affected, per Red Hat.
- Distribution packages can be patched while still reporting an older version number.
- Setting Protocols to http/1.1 is a valid stopgap, not a replacement for patching.
Frequently Asked Questions
Is CVE-2026-119618 being exploited in the wild?
As of 12 November 2026, the Cloud Security Alliance research note said no in-the-wild exploitation had been reported. The same note cites Red Hat’s statement that public research has shown a reliable exploit against a default server with mod_http2 enabled. Treat it as urgent and watch CISA’s Known Exploited Vulnerabilities catalog for changes.
How do I check if HTTP/2 is enabled in Apache?
Run apachectl -M and look for http2_module. Then search your enabled configuration for a Protocols line containing h2 or h2c. A live probe confirms it: curl –http2 against the site and check whether the response reports HTTP version 2. Module loaded plus h2 in Protocols means the server negotiates HTTP/2.
How do I disable HTTP/2 in Apache as a temporary workaround?
Set Protocols http/1.1 at server level and in every virtual host that sets its own Protocols value, or unload mod_http2. Run a config test, then restart Apache. Confirm with curl that responses now come back as HTTP/1.1. This removes the vulnerable code path but is a stopgap, not a fix.
Is Apache 2.4.58 on Ubuntu vulnerable to CVE-2026-119618?
The upstream version string alone cannot tell you. Distributions backport fixes without changing it. In our Ubuntu 24.04 test, package 2.4.58-1ubuntu8.19 listed this CVE in its changelog, so it carries the patch. Check your package revision and changelog, not just the output of apache2 -v.
This bug is a reminder that protocol features add concurrency, and concurrency adds risk. Find the servers that truly speak HTTP/2, patch them, and verify with a live probe. If you are tightening the rest of your stack, our guides on npm supply chain defense layers, rate limiter design and retry storm prevention cover the next layers. Subscribe to NexGismo for the next advisory breakdown.