Critical RCE Vulnerability in Apache HTTP Server
soheilpro
86 points
35 comments
November 12, 2026
Related Discussions
Found 5 related stories in 134.5ms across 12,324 title embeddings via pgvector HNSW
- CVE-2026-119618 (critical): mod_HTTP2: heap corruption and RCE in assign_headers klaas- · 28 pts · November 11, 2026 · 70% similar
- Critical Vulnerabilities in PHP defly · 21 pts · October 20, 2026 · 62% similar
- Pre-Authentication RCE in WordPress Core patrikg · 18 pts · July 17, 2026 · 62% similar
- Potential third critical PHP CVE mpaepper · 64 pts · October 21, 2026 · 62% similar
- PHP2Shell: AI uncovers critical RCE in PHP danlark1 · 440 pts · October 21, 2026 · 59% similar
Discussion Highlights (12 comments)
superkuh
It's not always HTTP/2. But it's a pretty safe bet.
koolba
Why does it say the “vendor” for this is GitHub (for mod_h2)? Is that just crappy LLM generated copy that is assuming that GitHub the company is responsible for that module because it’s hosted there?
kgeist
>Due to improper synchronization when executing concurrent threads sharing resources, an attacker can trigger heap corruption. >As of the time of this blog’s publication, no exploit is available and there are no reports of exploitation in the wild. Since when does "memory corruption" = "RCE"? Last week I found and reproduced a memory corruption (a use-after-free) in PHP's runtime after running an on-premise agent for just 30 minutes. There's nothing about it on the internet. Should I write a blog post about a scary new vulnerability? :)
thehamkercat
> What is CVE-2026-111497? > CVE-2026-119618 is a critical, high-severity vulnerability involving.... two CVEs? (111497 != 11968)
lakeviewterrace
Another critical bug discovered by AI. I want the rabidly AI-hating projects to stand their ground and refuse to fix vulnerabilities discovered with AI assistance.
wild_pointer
From 2.4.55 through 2.4.70? Jokes on you, my version is not that new!
TZubiri
all my handwritten sockets servers are fine because I use HTTP/1.1 I have 1 apache acting as a proxy for vhosts and > a2dismod http2 gives me > Module http2 already disabled I don’t want to tempt fate (and hackers ) but I have dodged lots of major vulns this year with my strategy of writing code by hand instead of pip installing everything only vuln I was exposed to was copy.fail, but that was a defense in depth weakness, and I was vulnerable to the kvm weakness if there was a malicious tenant in my host’s hypervisor, but that’s not fair I’m poor so I don’t have a dedi. maybe the tcp vuln was the most exposed I’ve been but that was a very short window that got auto upgraded by apt with a high attack complexity maybe I can write about how I survived 2026 without getting a supply chain vuln and get some work or students on new years? I feel that’ll be a pretty big accolade.
g-b-r
Even Apache is being filled with Claude commits, so great.....
fulafel
The C chansaw juggling doesn't get any safer from adding threads. Is the robust original (pre)fork configuration still supported?
throooooo
I have a lot of Linux sysadmin experience but haven't touched Apache in more than a decade. I thought it's mostly nginx or other solutions at this point.
jerrythegerbil
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.
tancop
HTTP2 is insecure and 1.1 is slow. At this point just find a good H3 implementation and drop the old protocols.