RCE Bug Found in NGINX (With AI Tools)

Ajouté : 2026-05-22

[00:00:00]If you have a public-f facing website, one of the worst bugs that could affect your online service is a remote code execution flaw in EngineX. And it turns out that one has existed in that program's codebase for over 18 years.

[00:00:12]Now, for those of you that don't deal with web apps, EngineX is the world's most popular web server. Most documentation assumes you're using it.

[00:00:19]Popular frameworks like WordPress default to it. And for most public-f facing servers, EngineX is the first piece of software that packets from the internet to interact with. So exploits in it are a pretty big deal, especially remote vulnerabilities like this one that don't require you to already have lowprivilege shell access to a server.

[00:00:38]And when you combine something like this with the several privilege escalation bugs that have been recently discovered, like copy fail, dirty frag, and fragnesia, you get pretty close to having an exploit chain that could let you root most web servers out there on the internet. The only reason that hasn't happened yet is because for one, the proof of concept for this remote exploit that people are calling EngineX Rift requires the target machine to have a pretty specific EngineX configuration.

[00:01:05]And it also requires you to disable memory protections that no sane person would turn off for a production server.

[00:01:11]But if you're running a web server, make sure you've updated EngineX to version 1.3.1 and 1.31.0 zero or later which contains the patch for this particular bug. So like I said a pretty specific config is required for this bug to work although that config is somewhat common in PHP web apps. A rewrite directive has to be followed by another rewrite related directive like rewrite if or set. The rule has to be reuse captured parts of a regular expression through numbered back references and the replacement string has to include a question mark. But if that exact pattern exists, the attack itself does not require a login. A remote attacker can send a crafted HTTP request to the server that corrupts heap memory inside the EngineX worker process, which is why this is such a big deal for rewrite heavy reverse proxies, API gateways, and ingress controllers.

[00:02:07]The root cause is a classic C memory safety failure hiding inside of EngineX's rewrite scripting engine.

[00:02:14]EngineX processes rewrite logic through an internal script system and the public depth first rewrite explains that the engine effectively does one pass to calculate how large a buffer should be and another pass to actually copy that data. The problem is that a question mark in the rewrite replacement sets an internal is state and that state was not cleared correctly. So the length calculation thinks it needs a smaller buffer, but the copy phase later escapes attacker controlled URI bytes, expanding some bytes into a longer encoded form, and the result is an undersized heap allocation followed by a right past the end of that allocation. Now let's talk about the denial of service attack that can be done with this because that's actually the more common exploit that servers on the internet are going to be vulnerable to. So, EngineX uses a master worker architecture and if a worker process crashes, the master can respawn it. And this is really great for availability under normal failures. But for a memory corruption bug, it also means that an attacker can keep sending crash triggering requests and keep forcing worker restarts resulting in a sustained denial of service. This is the most immediate and likely impact for servers because reliably turning the bug into remote code execution is a lot harder because of memory protections that are usually enabled by default in pretty much every Linux distro. So for the remote code execution exploit, the same rewrite and set directives have to be in use within engine X, but the target OS needs to also not have any memory protections like ASLR in place.

[00:03:54]So ASLR stands for address space layout randomization and as the name implies it randomizes the memory addresses that different parts of your program run in making it more difficult to reliably exploit memory corruption vulnerabilities. Most distros use full randomization which means that the stack the VDSO page shared memory regions and the data segment are going to use random addresses whenever EngineX runs. And this is why the proof of concept that was posted to GitHub isn't something that just random script kitties on the internet can use to hack people. Because if we actually look at the Python source code, the memory addresses are all hardcoded in the script. But in a real world scenario, these addresses would be randomized and you'd have to guess what the addresses are and there's way too many of them in order to brute force the location of those addresses. So realistically to make this work you need some kind of information leak to get the libby cy pointer or heat pointer in order to calculate a smaller set of addresses to successfully get remote code execution. And that's why you probably saw some people calling this exploit a nothing ber by itself because having those information leaks in the first place is a much bigger issue that opens you up to, you know, more attacks than just EngineX Rift. And you'd have to go out of your way to set up a Linux machine without full address base randomization because like I said, it's set up by default on pretty much every Linux distro, especially the ones that you would run a publicly facing server from. But it's important to point out that not every implementation of ASLR is created equally and depending on how the randomization is implemented on your system. There could be known unpatch exploits that are able to bypass those protections to leak the memory addresses of the lib C and the heap to get an exploit like this working. And even if there's not a currently published exploit for the ASLR, there might be one that could soon be found by AI, which by the way, I don't think I mentioned this yet, but this EngineX Rift exploit was also found with the assistance of an AI tool. According to Death First, the company that first confirmed and published this exploit after disclosing it to EngineX, they were able to scan the EngineX repo with their autonomous system, which found this critical vulnerability along with three other less severe ones in just 6 hours. And all of these issues have existed in the codebase for many, many years and have been missed by countless other researchers until these tools became available. And we're going to keep seeing bugs like this. And the disclosure windows are going to become tighter and tighter. The time from a bug being found to a patch being issued to the whole world knowing about it because these companies want to get the scary news out there as soon as possible since it serves as great marketing for their AI tools. And I know a lot of people are tired of hearing about AI and can't wait for the bubble to pop. But we got to be realistic right now about how much of a threat these autonomous vulnerability scanners really are. because I've been seeing some dangerous levels of copium from people in response to these recent exploits. First, with the privilege escalation bugs like copy fail and dirty frag, some people thought it was just no biggie because they weren't remotely exploitable. You needed to have some kind of shell access or at least the ability to upload and then execute a script to a server, which you know is a pretty big problem by itself. But now with this EngineX bug, I see people saying it's no biggie because ASLR makes it much harder to pull off and that's enabled on every machine even though denial of service attacks are still possible even with those memory protections in place. So, don't be that person that's still huffing the copium when AI discovers an ASLR bypass because it wouldn't take a genius to string together two or three different proof of concept exploits to start creating your own botnet with pone systems because I can assure you that there's a lot of machines out there that are still vulnerable to the Linux kernel exploits that I talked about earlier and there will be machines vulnerable to this exploit due to lack of patching for a long time to come. So stay up todate on the exploits AI discovered or otherwise and keep on patching your systems. If you enjoyed this video, please like and share it to hack the algorithm and check out my online store base.win, where you can buy my awesome merch or accessories for your phone or laptop. 10% storewide discount when you pay with Monero XMR at checkout. Have a great rest of your day.