--- title: Apache HTTP Server 2.4.71 patches critical HTTP/2 remote... description: Apache HTTP Server 2.4.71 fixes a critical remote code execution bug in mod_http2, tracked as CVE-2026-119618. The flaw is a race condition in the... canonical: https://daily.dev/posts/apache-http-server-2-4-71-patches-critical-http-2-remote-code-execution-flaw-cve-2026-119618--kxsdwc1gb twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Apache HTTP Server 2.4.71 patches critical HTTP/2 remote code execution flaw (CVE-2026-119618) | daily.dev og:description: Apache HTTP Server 2.4.71 fixes a critical remote code execution bug in mod_http2, tracked as CVE-2026-119618. The flaw is a race condition in the... og:url: https://daily.dev/posts/apache-http-server-2-4-71-patches-critical-http-2-remote-code-execution-flaw-cve-2026-119618--kxsdwc1gb og:image: https://api.daily.dev/og/posts/KxSdWc1GB.png og:image:alt: Apache HTTP Server 2.4.71 patches critical HTTP/2 remote code execution flaw (CVE-2026-119618) og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Apache HTTP Server 2.4.71 patches critical HTTP/2 remote code execution flaw (CVE-2026-119618) **[Collections](https://daily.dev/sources/collections)** · 1 min read · 0 upvotes · 0 comments ## Summary Apache HTTP Server 2.4.71 fixes a critical remote code execution bug in mod_http2, tracked as CVE-2026-119618. The flaw is a race condition in the `assign_headers()` function that corrupts heap memory, letting a remote, unauthenticated attacker run code with the web server's privileges. Anthropic and Google Cloud's Vulnerability Research Team found it independently. Versions 2.4.55 through 2.4.70 and standalone mod_h2 2.0.8 through 2.0.42 are affected, but only if HTTP/2 is enabled, which is off by default. Wiz data shows 64% of cloud environments have vulnerable resources and 51% have publicly exposed instances. The 2.4.71 release also patches CVE-2026-106023 and CVE-2026-109163. If you can't upgrade immediately, disable HTTP/2 by restricting the server to HTTP/1.1. ## Content Apache HTTP Server has fixed a critical remote code execution bug in mod_http2, tracked as CVE-2026-119618. The fix is in version 2.4.71. ## What the bug is It's a race condition in the `assign_headers()` function. Triggering it corrupts heap memory, and a remote, unauthenticated attacker can use that to run code with the web server's privileges. Anthropic and Google Cloud's Vulnerability Research Team found it independently. No public exploit exists yet, and no attacks in the wild have been reported. ## Who is affected - Apache HTTP Server 2.4.55 through 2.4.70 - Standalone mod_h2 2.0.8 through 2.0.42 Exploitation requires HTTP/2 to be enabled, which is off by default. That matters, but Wiz data shows how many setups could still be at risk: 64% of cloud environments have vulnerable resources, and 51% have publicly exposed instances. Those figures don't account for configuration, so the number actually exploitable is probably lower. ## What to do Upgrade to 2.4.71. The release also fixes two other bugs, CVE-2026-106023 and CVE-2026-109163. If you can't patch right away, turn off HTTP/2 by restricting the server's protocols to HTTP/1.1. That removes the vulnerable code path until you can update. ## Questions this post answers ### What is CVE-2026-119618 in Apache HTTP Server and how serious is it? It's a critical remote code execution vulnerability in mod_http2, caused by a race condition in the assign_headers() function that corrupts heap memory. A remote, unauthenticated attacker can exploit it to run code with the web server's privileges. It was found independently by Anthropic and Google Cloud's Vulnerability Research Team. No public exploit or in-the-wild attacks have been reported yet. _Teams running Apache can track patch status for flaws like this one on daily.dev._ ### Which versions of Apache HTTP Server and mod_h2 are affected by CVE-2026-119618? Apache HTTP Server versions 2.4.55 through 2.4.70 and standalone mod_h2 versions 2.0.8 through 2.0.42 are vulnerable. Exploitation requires HTTP/2 to be enabled, which is off by default, so not every deployment running these versions is automatically at risk. Upgrading to 2.4.71 fixes the flaw. _Anyone auditing server versions against new CVEs can keep an eye on disclosures like this via daily.dev._ ### How do I protect my Apache server from the mod_http2 RCE if I can't patch immediately? Disable HTTP/2 by restricting the server's protocols to HTTP/1.1, which removes the vulnerable code path until an upgrade is possible. The permanent fix is upgrading to Apache HTTP Server 2.4.71, which also resolves two other bugs, CVE-2026-106023 and CVE-2026-109163. _Ops teams weighing quick mitigations versus full upgrades can follow fixes like this through daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 105 comments across hackernews (as of 2026-11-12). **TL;DR:** Discussion centers less on panic and more on whether 'RCE' is an overstated label for what may just be heap corruption, alongside a long tangent about why people still use Apache and whether HTTP/2 itself was a mistake. **Sentiment:** 10% positive · 50% mixed · 40% skeptical **The case for** - Disabling HTTP/2 is seen as an easy, low-downside mitigation for most setups. - Some see AI-assisted vulnerability discovery as no different from established tools like fuzzers or static analyzers. **The pushback** - Several question whether 'memory corruption' truly equates to a demonstrated RCE without a public PoC. - Confusion over conflicting severity claims (RedHat says exploited, Wiz says no exploit) undermines confidence in the reporting. - Some find the advisory text sloppy/possibly AI-generated, citing a mismatched CVE number and an incorrect 'vendor' attribution. - A few argue HTTP/2 (and HTTP/3) added unjustified complexity that enables bugs like this. **By community** - hackernews (heated): Debate splits between skepticism over the 'RCE' framing and acceptance that heap corruption here is likely exploitable, layered with unrelated arguments about Apache's continued relevance, AI-assisted vuln discovery, and whether HTTP/2 was ever worth it. **Hottest debate:** Whether this bug truly constitutes a demonstrated RCE or is an overstated label for unproven memory corruption. **Open questions** - Does a working RCE proof-of-concept actually exist, or is severity being inferred from CVSS score alone? - What exactly counts as a 'cloud environment' in the Wiz exposure statistics? - Is LiteSpeed/OpenLiteSpeed also affected given they share code lineage with Apache's HTTP/2 handling? **Highlights** > RedHat claims there's a working RCE: > (...) public research has demonstrated a reliable exploit against a default-configured server with the mod_http2 module enabled. Successful exploitation allows an attacker to execute arbitrary commands, gain full control of the server process, and access or modify sensitive information. https://access.redhat.com/security/cve/cve-2026-119618 Discovered independently by Anthropic (Oct 26) and Google (Nov 3), so I'm compelled to believe it: https://httpd.apache.org/security/vulnerabilities_24 But maybe someone will post another HN challenge like with the PHP thing? > — [perching\_aix on hackernews](https://news.ycombinator.com/item?id=50462841) > One of the core claims of the language is data race safety because in safe rust, no memory location can be written by two or more owners at the same time. (see https://doc.rust-lang.org/nomicon/races.html for a more detailed discussion) Consequently, the kind of memory corruptions that this vulnerability seems to exploit are not possible in safe rust. Now, we don't know if a hypothetical rust-based apache implementation would have reached for unsafe in this context or done any other wild thing, but it's fair to assume that the likelihood of an exploitable RCE through memory corruption trends towards zero in programs written in Rust. > — [Xylakant on hackernews](https://news.ycombinator.com/item?id=50465274) > The details I've seen are too sparse to say with certainty, but it seems like the issue is concurrent access to the same value through a pointer. In particular it's `req` in the function with this signature: static void assign_headers(request_rec *r, const h2_request *req, int no_body, int is_connect) The fix being: - apr_table_setn(req->headers, "Content-Length", "0"); + apr_table_setn(r->headers_in, "Content-Length", "0"); My read on this is that `req` is meant to be a readonly value in this function, which is why it's marked `const`. And being readonly, it would be safe to access concurrently. However, someone accidentally wrote through this pointer. In Rust this would've been `req: &h2_request` and the accidental write wouldn't have been possible (barring interior mutability). Even with interior mutability there is no thread interleaving during the write, which happens through a `&mut h2_request` probably obtained through a lock. > — [K0nserv on hackernews](https://news.ycombinator.com/item?id=50465349) > I was prepared to disagree with you, but I agree: I'd say there's a strong norm of not calling things RCE unless you can actually demonstrate RCE, or at least have a clean pathway to demonstrating it (e.g. a full write-what-where). It's perfectly sufficient to have a CVE for just memory corruption, so the "RCE" framing here feels overstated. Particularly when an LLM should easily prove RCE out if it is in fact present. > — [woodruffw on hackernews · 1 comments](https://news.ycombinator.com/item?id=50462662) > This took 7 minutes and $0.02 in deepseek spend through a subscription to reproduce. The prompt was simply directed at a vulnerable version and told to find a h2 race, which is generically the most common culprit these days. Once it found one, I had it attempt the same against a patched version (which failed). Disabling h2 is the mitigation and is effective. The patch itself seems a little odd as a fix to me personally, but eh. > — [jerrythegerbil on hackernews · 2 comments](https://news.ycombinator.com/item?id=50463365) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50462177) · 210 points · 105 comments ## Similar posts on daily.dev - [Nginx, Apache, and more hit by DoS attack exploiting flaw in HTTP/2](https://daily.dev/posts/nginx-apache-and-more-hit-by-dos-attack-exploiting-flaw-in-http-2-lrfkdbwpy) · CSO Online · 0 upvotes · 0 comments - [New 'HTTP/2 Bomb' DoS attack crashes web servers in under a minute](https://daily.dev/posts/new-http-2-bomb-dos-attack-crashes-web-servers-in-under-a-minute-u9xatkol2) · BleepingComputer · 13 upvotes · 0 comments - [A 14-Year-Old PHP Bug Lets Strangers Run Code on Your Server. Here's How to Stop It](https://daily.dev/posts/a-14-year-old-php-bug-lets-strangers-run-code-on-your-server-here-s-how-to-stop-it-vd0nya50m) · Medium · 2 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security) [View this post on daily.dev](https://daily.dev/posts/apache-http-server-2-4-71-patches-critical-http-2-remote-code-execution-flaw-cve-2026-119618--kxsdwc1gb) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Apache HTTP Server 2.4.71 patches critical HTTP/2 remote code execution flaw (CVE-2026-119618)","url":"https://daily.dev/posts/apache-http-server-2-4-71-patches-critical-http-2-remote-code-execution-flaw-cve-2026-119618--kxsdwc1gb","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/apache-http-server-2-4-71-patches-critical-http-2-remote-code-execution-flaw-cve-2026-119618--kxsdwc1gb"},"datePublished":"2026-11-12T20:08:24.049Z","dateModified":"2026-11-12T20:09:10.363Z","description":"Apache HTTP Server 2.4.71 fixes a critical remote code execution bug in mod_http2, tracked as CVE-2026-119618. The flaw is a race condition in the...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0bcfb2a667c669b13447bad5a0511e31?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0bcfb2a667c669b13447bad5a0511e31?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/apache-http-server-2-4-71-patches-critical-http-2-remote-code-execution-flaw-cve-2026-119618--kxsdwc1gb","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security","timeRequired":"PT1M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"Apache HTTP Server 2.4.71 patches critical HTTP/2 remote code execution flaw (CVE-2026-119618)"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/apache-http-server-2-4-71-patches-critical-http-2-remote-code-execution-flaw-cve-2026-119618--kxsdwc1gb#faq","mainEntity":[{"@type":"Question","name":"What is CVE-2026-119618 in Apache HTTP Server and how serious is it?","acceptedAnswer":{"@type":"Answer","text":"It's a critical remote code execution vulnerability in mod_http2, caused by a race condition in the assign_headers() function that corrupts heap memory. A remote, unauthenticated attacker can exploit it to run code with the web server's privileges. It was found independently by Anthropic and Google Cloud's Vulnerability Research Team. No public exploit or in-the-wild attacks have been reported yet. Teams running Apache can track patch status for flaws like this one on daily.dev."}},{"@type":"Question","name":"Which versions of Apache HTTP Server and mod_h2 are affected by CVE-2026-119618?","acceptedAnswer":{"@type":"Answer","text":"Apache HTTP Server versions 2.4.55 through 2.4.70 and standalone mod_h2 versions 2.0.8 through 2.0.42 are vulnerable. Exploitation requires HTTP/2 to be enabled, which is off by default, so not every deployment running these versions is automatically at risk. Upgrading to 2.4.71 fixes the flaw. Anyone auditing server versions against new CVEs can keep an eye on disclosures like this via daily.dev."}},{"@type":"Question","name":"How do I protect my Apache server from the mod_http2 RCE if I can't patch immediately?","acceptedAnswer":{"@type":"Answer","text":"Disable HTTP/2 by restricting the server's protocols to HTTP/1.1, which removes the vulnerable code path until an upgrade is possible. The permanent fix is upgrading to Apache HTTP Server 2.4.71, which also resolves two other bugs, CVE-2026-106023 and CVE-2026-109163. Ops teams weighing quick mitigations versus full upgrades can follow fixes like this through daily.dev."}}]} ```