nginx-poolslip—AI Agent Found Unpatched RCE in 30% of the Web

Organizations that rushed to upgrade NGINX after last week’s nginx-rift patch now face a second, more dangerous vulnerability in the very same release. On May 20, security researcher Vega from the NebSec security team disclosed nginx-poolslip—an unpatched remote code execution zero-day in NGINX 1.31.0 that bypasses Address Space Layout Randomization, the OS-level memory protection that makes most exploitation attempts fail.

No CVE has been assigned. No patch exists. And NGINX powers roughly a third of all web servers on the internet.

What nginx-poolslip Actually Does

nginx-poolslip targets NGINX’s internal memory pool handling mechanism—the subsystem responsible for allocating and freeing memory across worker processes. According to ProbablyPwned’s analysis, the vulnerability enables unauthenticated remote attackers to bypass ASLR across major Linux distributions, achieve arbitrary code execution on the underlying server, and potentially compromise entire systems without any prior authentication.

The ASLR bypass is what makes this vulnerability stand apart from most memory corruption bugs. Normally, defeating ASLR requires a separate exploit primitive—attackers need one bug to leak a memory address and a second bug to redirect execution. nginx-poolslip eliminates that requirement entirely, making reliable exploitation feasible on unpatched systems without needing a standalone bypass.

NebSec’s disclosure confirms that the nginx-rift patch failed to fully remediate the underlying memory pool attack surface. The fix addressed the heap buffer overflow in the ngx_http_rewrite_module, but left the door open for nginx-poolslip to emerge in the updated codebase. The patch closed one door and left another one open.

The Patch-Then-Exploit Pattern

This is not a random coincidence. The timeline is instructive:

On May 13, NGINX disclosed CVE-2026-42945—nicknamed nginx-rift—a heap-based buffer overflow in the rewrite module carrying a CVSS v4 score of 9.2. The vulnerability had lurked in the codebase since 2008, exposing roughly 5.7 million internet-facing NGINX servers to denial-of-service attacks and conditional remote code execution. F5 patched it in NGINX Open Source 1.31.0, and administrators worldwide rushed emergency upgrades.

Seven days later, NebSec’s AI agent Vega found nginx-poolslip in that same 1.31.0 release.

The pattern is accelerating. Google’s AI-built zero-day from earlier this month showed that AI agents can find vulnerabilities humans miss. Cisco’s sixth SD-WAN zero-day of 2026 demonstrated that patching one vulnerability in a product line doesn’t close the underlying attack surface. nginx-poolslip combines both dynamics: an AI agent found a gap that a human-directed patch left behind.

When the patch for vulnerability A creates a known-patchy attack surface for vulnerability B, and an AI agent can systematically probe that surface, the traditional patch cycle starts to look like a losing proposition. Administrators patch, the vendor declares the issue resolved, and an AI agent finds the next gap in hours instead of years.

Scope of Exposure

NGINX powers an estimated 30 to 40 percent of all web servers globally, according to W3Techs and Daily Security Review. That includes production web infrastructure, reverse proxies, load balancers, and API gateways at organizations including Netflix, Cloudflare, and WordPress.com.

Any deployment running NGINX 1.31.0 or 1.30.1—the versions patched for nginx-rift—should be considered at risk. Older versions may also be affected, though NebSec has not released detailed version ranges.

Vega committed to withholding the full technical write-up and ASLR bypass details for 30 days following the release of an official patch. That 30-day clock has not started because no patch exists yet. The vulnerability’s existence and general characteristics are public, but the technical specifics that would allow direct weaponization are being held back pending vendor remediation.

What Admins Should Do Right Now

With no patch available, defenders are left with mitigation rather than remediation. The standard guidance applies: deploy web application firewalls in front of NGINX instances, restrict access to management interfaces, monitor for anomalous worker process behavior, and consider downgrading to an older stable branch if the nginx-rift vulnerability was not relevant to your configuration.

The uncomfortable truth is that nginx-rift required specific rewrite module configurations to be exploitable, while nginx-poolslip targets the core memory pool—a far more fundamental component present in virtually every NGINX deployment. GBHackers reports that the attack surface here is meaningfully broader than its predecessor.

F5 has not yet commented publicly on a remediation timeline. The 30-day responsible disclosure clock won’t start ticking until a patch ships—and until it does, tens of millions of servers run code that a security AI has already proven exploitable.

FAQ

What is nginx-poolslip?

An unpatched remote code execution zero-day in NGINX 1.31.0 that bypasses ASLR, a core operating system memory protection mechanism. It was discovered by an AI security agent named Vega from the NebSec team.

How is nginx-poolslip different from nginx-rift?

nginx-rift (CVE-2026-42945) was a heap buffer overflow in the rewrite module that required specific configuration to exploit. nginx-poolslip targets the core memory pool handling mechanism present in virtually every NGINX deployment and includes a built-in ASLR bypass.

Is there a patch available?

No. As of May 23, 2026, no CVE has been assigned and no official patch has been released by F5. NebSec is withholding full technical details for 30 days after a patch is released.

Who found nginx-poolslip?

Vega, an AI security agent operated by the NebSec (Nebula Security) team. Vega found the vulnerability in NGINX 1.31.0—the same version that patched nginx-rift just 7 days earlier.

How many servers are affected?

NGINX powers 30–40% of all web servers globally. Any deployment running version 1.31.0 or 1.30.1 should be considered at risk, though the exact number of vulnerable instances is unknown.