Sixteen Researchers Found the Same NGINX Bug at Once

The bug

The vulnerable pattern is specific. NGINX's map directive can key on a regular expression, and when it does, the regex can expose capture groups ($1, named captures) to later parts of the configuration. The overflow happens when a string expression references one of those regex capture variables before it references the map's own output variable, or when a non-cacheable variable is used in a string expression under certain conditions. In that ordering, NGINX mishandles the heap allocation backing the value, and a crafted request can overflow it inside the worker process.

The immediate result is a worker crash and automatic respawn, which at volume is a denial of service. The more serious ceiling is code execution: F5's advisory notes it is achievable on systems where Address Space Layout Randomization is disabled, or where the attacker can bypass ASLR. The attack is unauthenticated and delivered over ordinary HTTP, which is why it lands at CVSS 9.2 despite a high attack complexity: it needs the specific config and a groomable heap, not a foothold.

Who is exposed

Two things have to be true. First, you are running an affected build: NGINX Open Source from 0.9.6 up to and including 1.31.2, or an affected NGINX Plus release. Second, and this is the real gate, your configuration uses a regex map whose captures are referenced ahead of the map output in a downstream string expression, a log format, a proxied header, a set, or a chained map. Regex maps are common; that exact ordering is a narrower slice, so this is not universal, but it is also not exotic.

Sixteen finders, one bug

The detail worth pausing on is in the acknowledgments. F5 credited roughly sixteen researchers and teams who independently reported this same flaw, and several are AI-focused security shops. That is not a coincidence, it is the new baseline. AI-assisted source review has made deep reading of large open-source codebases cheap enough that many people now run the same passes over the same high-value targets at the same time, and they surface the same bug within days of each other.

This quietly breaks an assumption behind coordinated disclosure. The 90-day clock was designed for a world where a bug had one finder, or a few, who could hold it quietly while a vendor shipped a fix. When a dozen-plus independent parties are sitting on the same finding, the probability that it stays private, or that a proof of concept stays unpublished, drops fast. For defenders the takeaway is blunt: treat "independently reported by many" as a countdown, not a comfort. Patch as if the exploit is already written, because with that many finders it very likely soon will be.

How Caver detects it

There is no published exploit signature for 42533, so detection is behavioral and layered rather than a single payload match:

• Config is the precondition. The highest-fidelity signal is inventory: which of your NGINX hosts actually run a regex map with the vulnerable capture-before-output ordering. That set is your true exposure, independent of any request.
• Crash-loop is the runtime tell. Exploitation manifests as repeated worker-process crashes and respawns (SIGSEGV or SIGABRT) clustered in a short window, often alongside a spike in 502 and reset responses. A healthy NGINX fleet sees effectively zero worker segfaults, so a cluster is a strong, low-noise indicator.

Caver ships a Sigma detection for CVE-2026-42533 in the RedEye Intel Feed built on exactly that crash-loop logic, correlating worker segfault/respawn events per host over a short window. It is the same principle behind every detection we publish: we write about the bug, and we ship the rule that catches its exploitation.

The RedEye take

CVE-2026-42533 is a clean example of the moment we are in. The bug itself is a textbook heap overflow in one of the most deployed pieces of software on the internet, serious, but the kind of thing that gets patched every year. What is new is the shape of its discovery: sixteen independent finders, several of them machines pointed at source code, converging on one flaw at once. That compresses the safe window between disclosure and exploitation to almost nothing, and it rewards teams who patch on disclosure and detect in depth over teams who wait for a PoC to appear. Patch to 1.30.4 or 1.31.3, audit your regex maps, and watch your workers for crashes. The clock on this class of bug is only getting shorter.

Sources

NVD, CVE-2026-42533 (CVSS v4.0 9.2, CWE-122). nvd.nist.gov. F5 Security Advisory K000162097, "NGINX map directive and regex matching vulnerability." my.f5.com. NGINX security advisories and 2026 changelog (affected 0.9.6 to 1.31.2; fixed 1.30.4 / 1.31.3). nginx.org.