NGINX: three critical flaws, update to 1.30.6 / 1.31.7

A sysadmin never quite sleeps. PHP has barely been patched and F5 reports three critical flaws in NGINX Open Source and NGINX Plus, each rated CVSS 9.2. They can crash individual workers (DoS) and, under some conditions, lead to code execution. The good news: unlike PHP2Shell, not every installation is automatically exposed. It depends on specific directives. The bad news: there is no official interim mitigation, only the update.

The three flaws in one sentence each

CVE-2026-15176: heap overflow when alias meets rewrite plus a set or return that uses $request_filename. $request_filename in an access-log format is enough as well.
CVE-2026-97205: use-after-free when asynchronous file I/O (aio) is enabled and SSI pages with virtual includes are processed.
CVE-2026-93479: heap overflow with regular expressions in map when root or a log format uses capture variables before the map output.

All three affect the data plane only. Code execution additionally requires ASLR to be bypassed. No active attacks are known at the moment.

Which versions?

NGINX Open Source is fixed in 1.31.7 and 1.30.6. NGINX Plus in 37.1.0.1 and 37.0.5.1; R33 to R36 get no fix in their branch, only a migration helps. Older versions are partly affected too, back to very old releases.

Check in five minutes

nginx -v
nginx -T 2>/dev/null | grep -nE 'request_filename|^\s*aio\s|^\s*ssi\s+on'
nginx -T 2>/dev/null | grep -nE '^\s*map\s'
for c in $(docker ps --format '{{.Names}}'); do docker exec $c nginx -v 2>/dev/null && echo "  ^ $c"; done

The first line shows the version. The second searches the directives of the first two flaws in the complete, resolved configuration (including included files). The third lists every map block: look closely whether regular expressions with capture groups are used and whether those captures appear in root or a log_format. The last line finds NGINX inside containers, which are easy to forget.

Patch depending on where NGINX comes from

Distribution: apt update && apt upgrade and search the package changelog for the CVE numbers. Distributions often ship the fix under an old version number.
Panel (Plesk, cPanel): the panel brings its own NGINX. Don't replace it by hand; wait for the vendor's update and keep automatic updates on. Check the configuration until then.
Containers: move the image to nginx:1.30.6-alpine or newer. If you don't want to rebuild the app, swap only the runtime layer: new NGINX image as the base, copy the built files and templates from the old image, recreate the container.

Then nginx -t and a reload. For containers, recreate them, a restart is not enough.

What it looked like on my server

The NGINX in front of my websites comes from the panel and was on 1.30.5. No patched package was available there yet. Checking the complete configuration showed: no $request_filename, no aio, no SSI, and the map blocks use no captures. So not exploitable, and the update will arrive automatically once the vendor ships it. One container with its own NGINX was still on 1.29.8. I moved it to 1.30.6 right away, without rebuilding the app.

A few tips

No reason to panic, but no reason to leave it either. The configuration can change with the next deployment. What is not exploitable today may be tomorrow.
Check the resolved configuration (nginx -T), not just your own file. Many directives come from panel or package includes.
Don't forget containers: front ends, admin interfaces and office services often bring their own NGINX.
Avoid floating tags: FROM nginx:alpine is convenient, but you never know which version is running. Pin a concrete version and raise it on purpose.
Keep a small inventory: where NGINX runs, where PHP runs, which image is where. After PHP2Shell two days ago it has already paid off twice for me.

Sources: NGINX security advisories and the Cyber Security Agency of Singapore. For comparison: my post on the PHP emergency patch.