A widely-used open source web server has had a critical vulnerability hidden in it for nearly two decades, only recently brought to light by a team of researchers leveraging a custom commercial AI model.
The vulnerability allows an attacker to execute denial of service attacks, and under the right conditions could also open the door to remote code execution. However, other researchers point out that it is a proof-of-concept that may not be broadly usable in the real world due to very specific conditions that would be unusual for properly secured target systems, but has nevertheless earned a Common Vulnerability Scoring System (CVSS) rating of 9.2 due to its potential for damage.
Critical vulnerability threatens banks and cloud storage, but is hard to carry out
The critical vulnerability spans most of the history of NGINX, which was first made available in 2004. The web server is frequently used as a load balancer and cache for static content, and some recent estimates find that about 20 to 30% of the world’s busiest websites make use of it. Some of the more sensitive fields in which it is commonly used include banks and financial services, e-commerce platforms and cloud service providers.
The vulnerability, discovered by AI security firm DepthFirst and labeled as CVE-2026-42945, is a buffer overflow that can be triggered when a configuration uses both the “rewrite” and “set” directives. Though this is not an uncommon setup, other researchers have noted that the NGINX configuration must be using very particular rewrite patterns to be susceptible and this is likely why it has not been discovered before now. The attack also requires Address Space Layout Randomization (ASLR) protection to be disabled, something that is usually on by default (but is sometimes turned off to increase performance when using virtual machines or embedded systems).
Some independent researchers have called DepthFirst’s testing conditions “deliberately vulnerable” and question how realistic it would be for an attacker to pull this off in the wild. However, it is considered to be of high severity because of the realistic (if not likely) possibility of remote code execution. An attacker could send a single request that triggers an overflow in the worker process, without any requirement for prior authentication or even a prior session to be active.
Uzair Gadit, CEO and Founder of Secure.com, advises organizations to take the critical vulnerability seriously despite the apparent difficulties in crafting a reliable exploit for it: “The depthfirst team’s POC shows unauthenticated remote code execution against vulnerable servers, and they’ve noted that NGINX spawns identical replacement workers after each crash. This gives attackers unlimited retry attempts to defeat ASLR without the need for a separate information leak.”
“Teams need to upgrade to NGINX 1.31.0 (mainline) or 1.30.1 (stable) ASAP”, Gadit adds. “Don’t wait for a scheduled maintenance window. If a full upgrade isn’t possible immediately, then audit configuration files for the vulnerable pattern, and specifically for any combination of rewrite followed by set directives with the $args variable. Removing or restructuring that pattern blocks the trigger. Once patched, scan access logs for likely indicators of exploit attempts, such as unusual rewrite traffic and repeated worker crashes. Public PoC code already exists, so opportunistic scanning will follow quickly,” added Gadit.
The critical vulnerability was reported and patched in mid-April, but a broad range of NGINX builds (from 0.6.27, which was released in November 2008, all the way through April 2026’s 1.30.0) are impacted. Certain other projects and platforms, such as NGINX Gateway Fabric and Instance Manager, also have a range of their own releases impacted.
DepthFirst also reports three other NGINX flaws uncovered during their AI-based testing, though none of them is considered a critical vulnerability on par with this bug: these are CVE-2026-40701, CVE-2026-42934 and CVE-2026-42946.
Critical vulnerability discoveries stoke fears of unwinnable AI arms race
The researchers in this case appear to be using a custom-developed tool based on technology that is presently available to the general public, but announcement of the near-term release of frontier models such as Anthropic’s Claude Mythos have sparked something of a panic over the automation of critical vulnerability discovery and exploitation. For the moment Mythos remains available only to a limited selection of clients that require security testing of its advanced capabilities, such as government agencies and banks. The model burst into news cycles about a month ago with reports that it was able to discover 271 security vulnerabilities in Firefox 150 in short order, with some of these dating back as far as 15 years. By comparison, only 31 vulnerabilities were discovered in Firefox via more standard testing processes in all of 2025.
Opinions in the cybersecurity community vary on how capable these near-term frontier models will be in assisting attackers in carrying out breaches. But there seems to be general consensus that the pace of critical vulnerability discovery by AI will be stepping up to this level in a timeframe of months rather than years. Palo Alto Networks is one of the groups given advanced access to Mythos as well as OpenAI’s GPT 5.5-Cyber for testing, and has recently seen its “Patch Wednesday” advisories swell from an average of five to closer to 25 while using these tools.
John Carberry, Solution Sleuth at Xcape, warns: “The NGINX Rift vulnerability represents a massive surface area risk where the gap between a crash and a compromise depends entirely on local configuration. While unauthenticated remote code execution is the headline threat, the immediate business reality is a low-barrier denial-of-service that can bypass standard web application firewalls because the exploit resides in the core HTTP processing logic.”
Of course, as these examples demonstrate, AI can also be leveraged to quickly find and patch critical vulnerability issues. The reality of these advancing capabilities is not only that organizations will have to adopt appropriate defenses and testing, but will also need to take a closer look at code bases that have been around for decades and that were broadly thought to be “clean” and safe at this point.
