SURIQ
F5 has now shipped three critical, remotely reachable memory bugs in nginx since May, all rated 9.2, and the newest one quietly breaks the reassurance the last batch earned. In June we told you nginx's twin 9.2s were crashes rather than shells, and that a default server was not even in range because you had to be running HTTP/3 or proxying gRPC to reach them. CVE-2026-42533, patched on July 15, does not hand you that escape hatch. It fires inside nginx's string engine, the code that assembles values from your directives while a request is in flight, on a map pattern that a large share of real reverse-proxy and content-delivery configs already use. A static scanner for it is public, and the researchers put a working exploit at roughly three weeks after the patch. So the clock is shorter and the blast radius is wider than last month.
Why last month's "you are probably fine" does not carry over
In June the two nginx criticals, CVE-2026-42530 in the HTTP/3 QUIC module and CVE-2026-42055 in the HTTP/2 proxy and gRPC path, both needed non-default features switched on. A server terminating plain HTTP/1.1 and HTTP/2 was never reachable, so the honest triage was: check whether HTTP/3 is enabled, then patch on your normal cycle. CVE-2026-42533 sits somewhere else entirely. According to F5's advisory, the trigger is a map block that matches with a regular expression and then references its captured group inside a later string. That is not an exotic corner of nginx. Regex map with back-references is a workhorse for routing decisions, header rewrites, rate-limit keys, and access logging. So the question flips from "is a rare feature turned on" to "does any part of my config match a common shape," and for a lot of operators the answer is yes. That single change is why the calm advice from June does not transfer.
By The Hacker News's count this is the third overflow in the same expression-handling code inside roughly two months, after CVE-2026-42945 and CVE-2026-9256. Set that beside June's QUIC and HTTP/2 bugs and nginx has produced a run of 9.2-rated memory-safety criticals across three separate subsystems this summer. The common thread is hand-managed buffer sizing in C, and a two-pass step that measures how much space a value needs and then writes it, where the measuring pass and the writing pass can disagree about the size. That is a structural pattern, not three coincidences, and it argues for treating nginx patching as a standing monthly line item rather than a per-incident scramble. We have made the same case about edge devices that pile up a patch backlog; nginx now belongs on that list.
Which nginx builds and configs are actually in range
The vulnerable range is wide: it opens at 0.9.6, a build dating to 2011, and closes at 1.31.2. The fixes land in 1.30.4 on the stable branch, 1.31.3 on mainline, and NGINX Plus 37.0.3.1. A build is only exploitable if its config uses a regex map whose numbered capture feeds a later string, so version alone does not settle it.
The affected surface is broad because the bug is in the core server, not a plugin. Beyond the open-source server and NGINX Plus, F5 names the Ingress Controller, Gateway Fabric, Instance Manager, and the App Protect WAF. To decide whether a given host is reachable, inventory its configs for map directives that match with a regex and then reference the captured group ($1 through $9) inside a later set, return, add_header, proxy_set_header, or log-format string. Those are the ones on the hook. The public scanner from researcher Stan Shaw walks a config statically and flags exactly this shape, which makes it a fast first pass across a fleet before you touch a single package. Treat a clean scan as "deprioritize," not "immune," and patch anyway on your normal cycle.
What to do before the exploit lands
Patch first. Move to 1.30.4, 1.31.3, or NGINX Plus 37.0.3.1. That is the only complete fix. Bring the hosts your scan flags as config-matching current first, then the rest.
Treat the workaround as a stopgap, not a fix. F5's temporary guidance is to swap the numbered captures in the affected map blocks for named ones. The researcher who built the scanner warns that this narrows the path without shutting it, so do not let a config edit reset your patch urgency. A named-capture rewrite buys you time; it does not buy you safety.
Watch the impact, not a signature, until you patch. On a modern Linux host with address space layout randomization on, the dependable outcome is a worker that segfaults and respawns, not code execution. Alert on nginx worker SIGSEGV and restart loops, the same tripwire we described for June's bugs, and correlate it with whether the host's config matched your scan. That covers the denial of service today and flags exploitation attempts once a proof-of-concept circulates. It is the same discipline that separates teams who ride out a memory-corruption critical from teams who find out from an outage.
Mind the calendar. As of late July, CISA has not added the flaw to its Known Exploited Vulnerabilities catalog and no public exploit has surfaced, but the researchers scheduled exploit code for about three weeks past the July 15 fix, which lands in early August. The gap between "a scanner exists" and "an exploit exists" is your patch window, and it is closing.
On the code-execution question, the two accounts disagree, so plan for the worse one. F5 rates remote code execution as conditional, reachable only when ASLR is turned off or defeated, and frames a crash as the likelier outcome. Stan Shaw reports a working code-execution result on a default Ubuntu 24.04 install. Patch as if it is remote code execution, because the cost of guessing wrong in that direction is a shell, not a restart.
nginx is not having a bad week, it is having a bad quarter, and the shape of it is consistent: memory-safety bugs in C that only some configs reach. The teams who came through June calmly were the ones who already had an nginx version inventory and a worker-crash alert wired up. This bug rewards the same preparation, just with a wider net. Build the inventory, run the scanner, patch the matches first, and keep the crash-loop alert on. Then do it again next month, because on this evidence there will be a next one.
| CVE (patched) | nginx subsystem | Config needed to reach it | Default server in range? |
|---|---|---|---|
| CVE-2026-42530 (Jun) | HTTP/3 QUIC | HTTP/3 listener enabled | No |
| CVE-2026-42055 (Jun) | HTTP/2 proxy, gRPC | Upstream proxying with tuned header buffers | No |
| CVE-2026-42533 (Jul) | Script / map engine | Regex map with a numbered capture in a later string | Often |