Live data from Hacker News

New Nginx Exploit

github.com

21–30 of 116 posts

Re: New Nginx Exploit

#21
post #17
post #4

Wow, coming from the webdev world. It is so funny seeing NGINX, one of the widest used web servers in the world, on version 1.x. React is on version 19. Really shows how differently new vs. old software is designed and built, and not necessarily in a good way. https://world.hey.com/dhh/finished-software-8ee43637 https://josem.co/the-beauty-of-finished-software/

That's because nginx doesn't break things for end user every release, so there is no reason to bump major version.

I bet nginx doesn't even follow semantic versioning, which you seem to be talking about.

Re: New Nginx Exploit

#23

The POC disables aslr: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

Worker processes are forked from the master, which means they receive the same memory layout. You get unlimited crashes against the worker. There's probably a way to exploit that to get a read oracle. At the very least this is a reliable denial of service.

Depth First's full writeup: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

Re: New Nginx Exploit

#25
post #4

Wow, coming from the webdev world. It is so funny seeing NGINX, one of the widest used web servers in the world, on version 1.x. React is on version 19. Really shows how differently new vs. old software is designed and built, and not necessarily in a good way. https://world.hey.com/dhh/finished-software-8ee43637 https://josem.co/the-beauty-of-finished-software/

[deleted]

Re: New Nginx Exploit

#26
The official F5 page is here: https://my.f5.com/manage/s/article/K000161019

As noted elsewhere, ASLR protects you. While you are waiting for your affected platform to get the fix, they note the mitigation:

"use named captures instead of unnamed captures in rewrite definition"

"To mitigate this vulnerability for this example, replace $1 and $2 with the appropriate named captures, $user_id and $section"

F5 patched 1.31.0 and 1.30.1.

OpenResty has a patch for 1.27 and 1.29: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...

You can track OpenResty's (a Lua application server based on Nginx) progress here: https://github.com/openresty/openresty/issues/1119

Re: New Nginx Exploit

#27
As a security person it is tiring to see so many people here either directly claim or at least allude to the claim that this is somehow much less scary because the _published_ exploit does not bypass ASLR. The writeup claims there is a way to reliably bypass ASLR with this attack. And that is a good default assumption I would be willing to believe without evidence.

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.

It is straight up wrong to say "if you have ASLR enabled, you're not at any risk from this" and saying this is extremely harmful for anyone that trusts claims like that.

This wrong belief that you shouldn't care about security vulnerabilities because mitigations may make exploitation more difficult has already caused so much harm in the past. Be glad that modern mitigations exist, but patch your stuff asap. If you are a vendor, do not treat vulnerability reports as invalid because the researcher has not provided an ASLR bypass. Fix the root cause and hope mitigations buy you enough time to patch before you get owned.

Re: New Nginx Exploit

#28

Just saw this pop up — full public PoC for CVE-2026-42945 ("NGINX Rift"), a heap buffer overflow in NGINX's ngx_http_rewrite_module that's been there since 0.6.27 (2008). It triggers on a very common pattern: a `rewrite` directive (with an unnamed capture like $1/$2 and a `?` in the replacement string) followed by `set`, `if`, or another `rewrite`. The root cause is a classic two-pass script engine bug (length calcul…

[deleted]

Re: New Nginx Exploit

#29

The POC disables aslr: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

Worker processes are forked from the master, which means they receive the same memory layout. You get unlimited crashes against the worker. There's probably a way to exploit that to get a read oracle. At the very least this is a reliable denial of service. Depth First's full writeup: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

Sure, but I think the github README ought to make it more clear the POC as-is doesn't work against nginx on any current Linux distro.
Post reply on HN