Top
Best
New

Posted by soheilpro 11 hours ago

Critical RCE Vulnerability in Apache HTTP Server(www.wiz.io)
256 points | 123 commentspage 3
superkuh 10 hours ago|
It's not always HTTP/2. But it's a pretty safe bet.
userbinator 9 hours ago|
The vulnerability affects deployments utilizing HTTP/2 capabilities
g-b-r 8 hours ago||
Even Apache is being filled with Claude commits, so great.....
g-b-r 8 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
perching_aix 8 hours ago|||
[dead]
pixel_popping 8 hours ago||
You prefer to leave it insecure?
g-b-r 8 hours ago||
It was a comment unrelated to this vulnerability
TZubiri 9 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.

perching_aix 8 hours ago|
isn't http/1.1 request smuggling a known risk in exactly the scenario you're using it in?
hypfer 6 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?

cubefox 6 hours ago||
No CVSS severity level?
8-prime 4 hours ago|
NIST doens't show one (yet?). I checked on RedHat and they list it at a 9.8
cubefox 4 hours ago||
That's crazy high.
yoy0721 1 hour ago||
[flagged]
tgma 5 hours ago||
Time for a Rust based httpd replacement like https://xin.dev
hnarn 5 hours ago||
How would Rust have fixed this security issue?
Ukv 2 hours ago|||
> > a concurrent execution race condition within the assign_headers() function when handling shared resources [...] can corrupt heap memory to achieve arbitrary code execution (RCE)

To my understanding, in safe Rust to share between threads the compiler will require something like Arc<Mutex<...>> - which prevents unsynchronized access or freeing while another thread is still using it.

Xylakant 2 hours ago||||
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.
K0nserv 2 hours ago||||
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.

flossly 5 hours ago|||
They've published an article last month on the Nginx vulnerabilities in light of their Rust implementation.

https://xin.dev/blog/multiple-nginx-vulnerabilities/

hnarn 3 hours ago||
If you’re going to respond, at least make an attempt to answer the question.
flossly 39 minutes ago||
It's not for Apache, that may be too recent (no blog post yet. For if you want to see how Rust can prevent vulnrs, the blog post explains it nicely.

Sorry for you I did not meet your standards. Pfff.

flossly 5 hours ago|||
Cannot find the source... (Wanted to see if they use the RusTLS)
mono442 2 hours ago||
this looks vibecoded which is probably even worse
tancop 7 hours ago||
HTTP2 is insecure and 1.1 is slow. At this point just find a good H3 implementation and drop the old protocols.
nine_k 6 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.
account42 2 hours ago||
Well there's HTTP/0.9. Can't get much simpler than that.
krembo 6 hours ago||
Wiz is such an amazing company. Israeli-based and recently acquired by Google, the significance of their security contributions cannot be overstated.
lakeviewterrace 9 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.

jonhohle 8 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.

yjftsjthsd-h 6 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.

jamesfinlayson 7 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.

JodieBenitez 7 hours ago|||
cough Zig... cough

> No LLMs for finding bugs.

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

Why?

perching_aix 8 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
patchtopic 5 hours ago||||
because it's just some slop generated by a bunch of stochastic parrots and can't be taken seriously :-)
lakt42t 9 hours ago|
[dead]