Is there a version of ingress-nginx somewhere with a fix for this?
New Nginx Exploit
81–90 of 116 posts
Re: New Nginx Exploit
#82Is there a good alternative to Apache and Nginx that's written in a memory-safe language and not full of security holes? I briefly looked at Jetty (written in Java) and Caddy (written in Go) but they seem to have a history of vulnerabilities of other types (e.g. shell injection in Jetty) so I'm not sure they would be any better.
Caddy been a breeze to use, bit sucky model with "we have thousands of binaries depending on what combination of plugins you want" instead of a proper plugin system, but if you're building it from source, it's pretty nifty and simple anyways.
That is a consequence of static linking, and an abandoned plugin package that hasn't yet been removed due to backwards compatibility.
People keep forgetting that with static linking they are back to 1980's IPC for application extensions, or building from scratch every time they need to reconfigure the application.
Re: New Nginx Exploit
#83Earlier quoted context omitted.
> Apache used forked processes; I don't think that's unique or a particular issue. Of course it is... in a typical threaded daemon, the threads have randomized stack addresses. Exactly as you observed, you get unlimited tries because nginx dutifully restarts the worker process with the same literal stack address every time it segfaults. I'm willing to bet the ASLR break they claim to have relies on that, but I'd be h…
This a heap exploit. Threads share heap access with the main process.
I mean... you're missing the forest for the trees, but yes I meant "address space" generally not "stack" specifically. The nginx threads are forked, it would not be that terribly complex to set up a heap with a new random address base in each worker (the only real complexity is dealing with heap allocations which happened before fork()). But the stack matters too, generally moreso.
Re: New Nginx Exploit
#84Earlier quoted context omitted.
> ASLR is a defense-in-depth technique intended to make exploitation more difficult. In almost all cases it is only a matter of time and skill to also include an ASLR bypass. Both requirements continue being lowered by LLM agents every few weeks. It is only a matter of time (and probably not a lot of time) until a fully weaponized exploit is developed. It may be published, it may also be kept private. I disagree with…
Anyone even vaguely familiar with exploiting nginx knows that ASLR is a complete non-factor here.
Could you explain for those who are not? :)
Re: New Nginx Exploit
#85[dead]
Re: New Nginx Exploit
#86Earlier quoted context omitted.
> ASLR is a defense-in-depth technique intended to make exploitation more difficult. In almost all cases it is only a matter of time and skill to also include an ASLR bypass. Both requirements continue being lowered by LLM agents every few weeks. It is only a matter of time (and probably not a lot of time) until a fully weaponized exploit is developed. It may be published, it may also be kept private. I disagree with…
Anyone even vaguely familiar with exploiting nginx knows that ASLR is a complete non-factor here.
Bold claim without any provided source. Do you have a link to back up that ASLR is a complete non-factor?
Re: New Nginx Exploit
#87Earlier quoted context omitted.
This a heap exploit. Threads share heap access with the main process.
I mean... you're missing the forest for the trees, but yes I meant "address space" generally not "stack" specifically. The nginx threads are forked, it would not be that terribly complex to set up a heap with a new random address base in each worker (the only real complexity is dealing with heap allocations which happened before fork()). But the stack matters too, generally moreso.
In your software, you set up a new heap for every pthread? I have never encountered this design pattern and would like to learn more.
Re: New Nginx Exploit
#88[deleted]
Re: New Nginx Exploit
#89Earlier quoted context omitted.
Anyone even vaguely familiar with exploiting nginx knows that ASLR is a complete non-factor here.
Bold claim without any provided source. Do you have a link to back up that ASLR is a complete non-factor?
I'm deliberately refraining from giving a ready LLM prompt.
History shows that "meh, ASLR mitigates this" is a vastly bolder claim anyway, so I don't feel much need to defend my position here.
Edit: Even the authors of this poc seem to agree with me https://depthfirst.com/research/nginx-rift-achieving-nginx-r...
Re: New Nginx Exploit
#90Is there a good alternative to Apache and Nginx that's written in a memory-safe language and not full of security holes? I briefly looked at Jetty (written in Java) and Caddy (written in Go) but they seem to have a history of vulnerabilities of other types (e.g. shell injection in Jetty) so I'm not sure they would be any better.
nginx just has logical errors in addition to buffer overflows, e.g. CVE-2026-42946.