Critical RCE Vulnerability in Apache HTTP Server
148 points by soheilpro 6 hours ago | 67 comments

spuz 13 minutes ago
I don't understand what they mean by "51% of cloud environments" have a publicly exposed instance. What is a "cloud environment"? Do they mean a cloud hosting provider like AWS or Google? Are they saying that between those two only one of them has an instance of a vulnerable Apache server running?
reply
throooooo 3 hours ago
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.
reply
orev 3 hours ago
At least 21% of web sites use Apache httpd, and of course many sites don’t report the software used at all. Nginx is also frequently used as a reverse proxy, with Apache used behind it.
reply
load-bearing 30 minutes ago
Apache has mod_md -- an acme client, which lets you obtain https certificates as easily as on caddy, without integrating with awkward separate programs.

https://httpd.apache.org/docs/trunk/mod/mod_md.html

reply
nine_k 2 hours ago
Apache has plenty of life left, it just works™, supports almost everything, and currently is about as efficient as nginx WRT connection handling. Sometimes you want what .htacces gives you. (No built-in Lua though.)
reply
iririririr 3 minutes ago
i mostly use nginx lua to patch on some feature i had even on bare Apache, let alone all the core modules.
reply
JodieBenitez 3 hours ago
At work we use Apache because of mod_shib. We have yet to try nginx-http-shibboleth.
reply
skeletal88 48 minutes ago
Why would I not use apache if everything already works with it for me?
reply
dawnerd 2 hours ago
Default Wordpress docker image uses it.
reply
tgma 34 minutes ago
Time for a Rust based httpd replacement like https://xin.dev
reply
flossly 50 seconds ago
Cannot find the source... (Wanted to see if they use the RusTLS)
reply
hnarn 9 minutes ago
How would Rust have fixed this security issue?
reply
thehamkercat 5 hours ago
> What is CVE-2026-111497?

> CVE-2026-119618 is a critical, high-severity vulnerability involving....

two CVEs? (111497 != 11968)

reply
kbenson 4 hours ago
I saw that too. CVE-2026-111497 is the Brotli CVE, so my guess is they reused that prior page as a base to start with and missed changing that.
reply
2bird3 4 hours ago
You'd think they'd have an LLM reviewing this by now. On the up side, it is refreshing to see good ol' human error still around on the surface!
reply
davisr 2 hours ago
What makes you think it's not already an LLM error?
reply
spuz 18 minutes ago
If you use modern LLMs a lot you'll know they are much better at catching these kind of copy and paste errors than humans are.
reply
brabel 2 hours ago
Even a tiny model would pick up an error like this during review.
reply
z3ratul163071 2 hours ago
what is amazing, there are no apache updated containers / packages available yet.
reply
Deukhoofd 7 minutes ago
Why are these things being disclosed before fixes have been rolled out? Is no-one following disclosure protocols any more?
reply
hypfer 56 minutes ago
At least disabling http2 is an easy countermeasure that will probably in most setups not have any real downsides.

If it was even enabled that is.

reply
jerrythegerbil 3 hours ago
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.

reply
NitpickLawyer 3 hours ago
Did it manage to produce a PoC for RCE? Apparently Redhat claimed there's a RCE, while Wiz said they don't have one.
reply
lifeisloving 3 hours ago
[dead]
reply
EGreg 26 minutes ago
http2 race??

What exactly is the issue and does nginx have it

reply
yunuserturk 2 hours ago
LiteSpeed and OpenLiteSpeed affected by this?
reply
jaekwon 26 minutes ago
gno.security/repairer
reply
cubefox 2 hours ago
No CVSS severity level?
reply
tancop 3 hours ago
HTTP2 is insecure and 1.1 is slow. At this point just find a good H3 implementation and drop the old protocols.
reply
nine_k 2 hours ago
Not everything benefits from pipelineling and multiplexing. I wish there existed a protocol that's even simpler than HTTP 1.1, which would be good for exposing APIs. Something like Thrift, but maybe even simpler and more bulletproof.
reply
kgeist 5 hours ago
>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? :)

reply
woodruffw 5 hours ago
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.

reply
uptrails 59 minutes ago
I don't know the backstory here, but there's a long and colorful history of vendors and other parties guessing that some contrived memory corruption bug isn't exploitable and then being proven wrong, so the industry now more or less defaults to the assumption that it's exploitable.

Let me remind you that in response to the PHP bug, one of the front-page HN posts was a guy saying it's probably not exploitable and another offering Bitcoin to anyone who pops their server... with predictable results.

People can be pretty creative with exploitation primitives, and LLMs now replicate that at a scale. And yep, if you found a use-after-free that can be triggered remotely in PHP under some reasonable assumptions, you should probably treat it as a security bug.

reply
fooqux 5 hours ago
If you can corrupt memory in a controllable way, you can get a computer to do just about anything that process has rights to. Possibly even the kernel, if you can get at some shared memory.
reply
kgeist 5 hours ago
But it's not a given that memory corruption is exploitable as an RCE specifically. I thought to call something an RCE you need a working exploit?
reply
stonogo 5 hours ago
Presumably one of Anthropic, Google, or Apache possesses a working exploit, because the official Apache Foundation report on this CVE claims RCE is possible.
reply
edoceo 5 hours ago
Isn't resource consumption a DoS?
reply
woodruffw 5 hours ago
A denial of service is a different class of vulnerability (a minor one, generally).
reply
perching_aix 5 hours ago
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?

reply
koolba 5 hours ago
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?

reply
stonogo 5 hours ago
Yes, this is slop, extruded from reading the patch and the official announcement, which is at https://httpd.apache.org/security/vulnerabilities_24.html#CV...
reply
Drupon 4 hours ago
[dead]
reply
wild_pointer 5 hours ago
From 2.4.55 through 2.4.70? Jokes on you, my version is not that new!
reply
jamesfinlayson 2 hours ago
Well I know someone who will get bitten - a couple of years I did some work (because security said so) to make sure we always pulled latest Apache when building our Docker container. Someone ripped that change out not long ago because it was too hard to maintain the Debian repo config changes needed to pull it in, and as a result they'll probably get stung by having a version right in the meaty part of that range.
reply
toast0 4 hours ago
I'm guessing you missed out on Heartbleed too :P At work we managed to upgrade to a vulnerable version 1 month before that came out .... ugh
reply
haradion 34 minutes ago
This has not been a good month for the LAMP stack…
reply
fulafel 3 hours ago
The C chansaw juggling doesn't get any safer from adding threads. Is the robust original (pre)fork configuration still supported?
reply
toast0 2 hours ago
I run apache with prefork on my personal sites. Still works. No idea if it supports http/2.
reply
fock 2 hours ago
I don't know, but Claude is fixing that too! (doubt that makes it safer either...)
reply
superkuh 6 hours ago
It's not always HTTP/2. But it's a pretty safe bet.
reply
userbinator 5 hours ago
The vulnerability affects deployments utilizing HTTP/2 capabilities
reply
g-b-r 4 hours ago
Even Apache is being filled with Claude commits, so great.....
reply
g-b-r 4 hours ago
I don't know why your comment is dead, but I meant in general perching_aix , it's just what I noticed looking up this
reply
pixel_popping 3 hours ago
You prefer to leave it insecure?
reply
g-b-r 3 hours ago
It was a comment unrelated to this vulnerability
reply
perching_aix 4 hours ago
[dead]
reply
TZubiri 4 hours ago
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.

reply
perching_aix 4 hours ago
isn't http/1.1 request smuggling a known risk in exactly the scenario you're using it in?
reply
hypfer 2 hours ago
If I understand correctly that only affects reverse proxy chains, which people might just not have. Or not have in a way that is vulnerable to that?

I guess it makes sense that "the cloud" moves to it, but beyond that, it might be fine?

reply
krembo 2 hours ago
Wiz is such an amazing company. Israeli-based and recently acquired by Google, the significance of their security contributions cannot be overstated.
reply
lakeviewterrace 5 hours ago
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.

reply
jonhohle 4 hours ago
Depending on the context and content, I tend to be against AI pull requests that haven’t been edited by a human.

AI finding vulns? I don’t see how it’s different from valgrind, static analysis, afl, or other fuzzer. I don’t think getting fresh, high-signal analysis is what AI-hating projects are concerned with.

reply
yjftsjthsd-h 2 hours ago
Depends on exactly what it is that a project is objecting to. For example, here's Nura:

> AI tools have several ethical issues. They require an unreasonable amount of energy[1] and water[2] to build and operate, their models are built in part with heavily exploited workers in unacceptable working conditions[3], usually without consent from or compensation for creators of the source material[4] and oftentimes causing DDoS attacks against FOSS infrastructure in the process[5] (which in turn force the deployment of challenge-based protections and increase cost and complexity of self-hosting for everybody[6]). Furthermore, they are being used to undermine labor and justify layoffs[7]. These are harms that we do not want to perpetuate, even if only indirectly.

( https://docs.nura.eco/policies-and-processes/development/ai-... )

If you really believe that AI tools are automatically unethical because they destroy the environment, harm workers, and constitute an attack on FOSS infrastructure, then it doesn't really matter how the tool is being used. If you just don't want to see code quality decline, then it's probably not a problem.

reply
jamesfinlayson 2 hours ago
> Depending on the context and content, I tend to be against AI pull requests that haven’t been edited by a human.

I've seen on a few open source projects I follow the 100% AI patch with notes to the effect of "I haven't compiled let alone tested these changes but AI said it's fine and my cursory glance agrees".

Like come on - I'm not going to judge using AI to make a useful change, but at least put in more than zero effort.

reply
JodieBenitez 3 hours ago
cough Zig... cough

> No LLMs for finding bugs.

reply
nozzlegear 5 hours ago
> I want the rabidly AI-hating projects to stand their ground and refuse to fix vulnerabilities discovered with AI assistance.

Why?

reply
patchtopic 11 minutes ago
because it's just some slop generated by a bunch of stochastic parrots and can't be taken seriously :-)
reply
perching_aix 4 hours ago
same reason i'd imagine that one might have wanted medical assistance be denied to covid deniers who inevitably did contract covid, and started experiencing the FO part of FAFO: retribution and consistency
reply
lakt42t 4 hours ago
[dead]
reply