--- title: Critical RCE Vulnerability in Apache HTTP Server | daily.dev description: A critical race condition vulnerability, CVE-2026-119618, hits Apache HTTP Server's HTTP/2 module (mod_http2). The bug sits in the assign_headers() function... canonical: https://daily.dev/posts/critical-rce-vulnerability-in-apache-http-server-acdiabsjp twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Critical RCE Vulnerability in Apache HTTP Server | daily.dev og:description: A critical race condition vulnerability, CVE-2026-119618, hits Apache HTTP Server's HTTP/2 module (mod_http2). The bug sits in the assign_headers() function... og:url: https://daily.dev/posts/critical-rce-vulnerability-in-apache-http-server-acdiabsjp og:image: https://api.daily.dev/og/posts/acDIABsJP.png og:image:alt: Critical RCE Vulnerability in Apache HTTP Server 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. # Critical RCE Vulnerability in Apache HTTP Server **[Hacker News](https://daily.dev/sources/hn)** · 5 min read · 3 upvotes · 0 comments ## Summary A critical race condition vulnerability, CVE-2026-119618, hits Apache HTTP Server's HTTP/2 module (mod_http2). The bug sits in the assign_headers() function and lets a remote, unauthenticated attacker corrupt heap memory to achieve arbitrary code execution. It was independently found by Anthropic and Google Cloud's Vulnerability Research Team. No exploit is public yet and no in-the-wild attacks have been reported. Wiz data shows 64% of cloud environments have vulnerable resources and 51% have publicly exposed instances, not accounting for configuration. Affected versions run from 2.4.55 through 2.4.70, patched in 2.4.71. If patching isn't immediately possible, disabling HTTP/2 by restricting protocols to HTTP/1.1 mitigates the risk. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is CVE-2026-119618 and how does it affect Apache HTTP Server? CVE-2026-119618 is a critical race condition vulnerability in Apache HTTP Server's HTTP/2 module (mod_http2), specifically in the assign_headers() function. Improper synchronization during concurrent thread execution on shared resources lets a remote, unauthenticated attacker corrupt heap memory and achieve arbitrary code execution with the web server process's privileges. _Teams patching web servers against new CVEs can track disclosures like this one on daily.dev._ ### Which Apache HTTP Server versions are affected by CVE-2026-119618 and what version fixes it? Versions from 2.4.55 through 2.4.70 are affected; the fix ships in 2.4.71 and later. Standalone builds of the mod_h2 module from GitHub are affected from 2.0.8 through 2.0.42, patched in 2.0.24 and newer. Upgrading is the recommended remediation. _Anyone deciding how fast to roll out this Apache patch can follow coverage on daily.dev._ ### How can I mitigate CVE-2026-119618 in Apache HTTP Server if I can't patch immediately? Temporarily disable HTTP/2 support to remove the attack vector, since the flaw lives in mod_http2. In the configuration file (such as httpd.conf), restrict active protocols to HTTP/1.1 by removing h2 and h2c references, using a directive like 'Protocols http/1.1'. _Ops teams weighing stopgap fixes for server vulnerabilities can keep up with advisories on 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 - [PHP patches released for two critical RCEs](https://daily.dev/posts/php-patches-released-for-two-critical-rces-w11cardmr) · LWN.net · 0 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 - [Security advisory: CVE- 2026- 110944: Resource exhaustion vulnerability in HTTP request handling impacts Qt HTTP Server \(QHttpServer\)](https://daily.dev/posts/security-advisory-cve--2026--110944-resource-exhaustion-vulnerability-in-http-request-handling-imp-fzl1ehnz2) · Qt · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security) [View this post on daily.dev](https://daily.dev/posts/critical-rce-vulnerability-in-apache-http-server-acdiabsjp) ```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":"Critical RCE Vulnerability in Apache HTTP Server","url":"https://daily.dev/posts/critical-rce-vulnerability-in-apache-http-server-acdiabsjp","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/critical-rce-vulnerability-in-apache-http-server-acdiabsjp"},"datePublished":"2026-11-12T06:23:40.854Z","dateModified":"2026-11-12T20:08:55.349Z","description":"A critical race condition vulnerability, CVE-2026-119618, hits Apache HTTP Server's HTTP/2 module (mod_http2). The bug sits in the assign_headers() function...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/ca49f146d8ba684986b5f8c7ac9ac1a4?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/ca49f146d8ba684986b5f8c7ac9ac1a4?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","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":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/critical-rce-vulnerability-in-apache-http-server-acdiabsjp","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Critical RCE Vulnerability in Apache HTTP Server"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/critical-rce-vulnerability-in-apache-http-server-acdiabsjp#faq","mainEntity":[{"@type":"Question","name":"What is CVE-2026-119618 and how does it affect Apache HTTP Server?","acceptedAnswer":{"@type":"Answer","text":"CVE-2026-119618 is a critical race condition vulnerability in Apache HTTP Server's HTTP/2 module (mod_http2), specifically in the assign_headers() function. Improper synchronization during concurrent thread execution on shared resources lets a remote, unauthenticated attacker corrupt heap memory and achieve arbitrary code execution with the web server process's privileges. Teams patching web servers against new CVEs can track disclosures like this one on daily.dev."}},{"@type":"Question","name":"Which Apache HTTP Server versions are affected by CVE-2026-119618 and what version fixes it?","acceptedAnswer":{"@type":"Answer","text":"Versions from 2.4.55 through 2.4.70 are affected; the fix ships in 2.4.71 and later. Standalone builds of the mod_h2 module from GitHub are affected from 2.0.8 through 2.0.42, patched in 2.0.24 and newer. Upgrading is the recommended remediation. Anyone deciding how fast to roll out this Apache patch can follow coverage on daily.dev."}},{"@type":"Question","name":"How can I mitigate CVE-2026-119618 in Apache HTTP Server if I can't patch immediately?","acceptedAnswer":{"@type":"Answer","text":"Temporarily disable HTTP/2 support to remove the attack vector, since the flaw lives in mod_http2. In the configuration file (such as httpd.conf), restrict active protocols to HTTP/1.1 by removing h2 and h2c references, using a directive like 'Protocols http/1.1'. Ops teams weighing stopgap fixes for server vulnerabilities can keep up with advisories on daily.dev."}}]} ```