nginx Fixed Five Bugs This Week. Which Ones Reach a WordPress Server?

On 14 October nginx released 1.30.6 and 1.31.7 with fixes for five security bugs. The headlines called it three memory corruption flaws that could lead to code execution, a TLS bug that skips client certificate checks, and an HTTP/3 request smuggling issue, which is accurate and also not very useful, because every one of the five only applies if a specific directive is in your configuration. These are the twenty-second to twenty-sixth nginx CVEs of 2026, so it is worth getting into the habit of reading the conditions rather than the headline.

The five, in order of how likely they are to reach you

CVE-2026-97629, session forgery with TLS session tickets. Rated 8.3. If ssl_session_cache shared:... is set and there is no explicit ssl_session_ticket_key, nginx rotates its ticket keys automatically, and a bug in that rotation leaves one key slot holding uninitialised memory. An attacker can forge a session that decrypts under it, and a forged session skips the handshake, including client certificate verification. That last part is the impact: it only matters if you verify client certificates, which on a WordPress origin means something like Cloudflare's authenticated origin pulls. There is a second reason most WordPress servers are fine. If certbot configured your TLS, it included /etc/letsencrypt/options-ssl-nginx.conf, and that file sets ssl_session_tickets off. No tickets, no forgery. Check with:

grep -r "ssl_session_tickets\|ssl_verify_client" /etc/nginx /etc/letsencrypt 2>/dev/null

If tickets are on and you verify client certificates, this one is yours.

CVE-2026-15176, buffer overflow with alias and rewrite. Rated 8.1. It needs a location that uses alias together with rewrite and a set or return that references $request_filename, or $request_filename used in a log_format. The impact is a worker crash, with code execution only where ASLR is off or defeated. Almost no WordPress configuration has that combination. Passing $request_filename to fastcgi_param SCRIPT_FILENAME, which nearly every WordPress configuration does, is not among the published conditions. Check anyway:

grep -rn "request_filename\|alias" /etc/nginx

CVE-2026-93479, buffer overflow in script evaluation. Needs a map that uses regular expression matching, with root or a log_format referencing the regex capture variables before the map's output variable. If you have never written a map block you do not have this. If you have, look at it.

CVE-2026-95101, request body injection in HTTP/3. Rated 5.3. Needs HTTP/3 enabled, meaning listen 443 quic somewhere, with proxy_request_buffering on, which is the default. Part of an unknown frame can be treated as request body, which can bypass client_max_body_size or add data to a proxied request. Most WordPress servers do not speak HTTP/3 directly; if you are behind Cloudflare, it does HTTP/3 at the edge and talks to your origin over HTTP/1.1 or 2. The September release, 1.30.5, fixed a separate HTTP/3 overflow with the same precondition.

CVE-2026-97205, use-after-free with SSI and AIO. Needs server-side includes switched on and asynchronous file I/O. Both are off by default and neither has any role in a WordPress setup.

The version question

nginx -v tells you what you are running, and if you installed from nginx.org's repository, 1.30.6 is what you want and apt upgrade gets it. If you installed from Ubuntu's own archive, the picture is different. Ubuntu 24.04 ships nginx 1.24.0 and 22.04 ships 1.18.0, and security fixes arrive as backports into those versions, so the number never changes. As of today Ubuntu's security tracker lists all five of this week's CVEs as "needs evaluation" for 22.04, 24.04 and 26.04, meaning no backport has shipped yet. Debian has fixed them in trixie and lists bookworm as vulnerable.

So on a distribution package the honest status is: not patched, probably not reachable, check your config. That is a reasonable place to be for a week. It is not a reasonable place to be for a quarter, and distribution nginx packages do sometimes sit in "needs evaluation" for a long time because the maintainers have made the same judgement about reachability that you just did. If you run nginx on a VPS and want the fixes when nginx publishes them, nginx.org's repository is the straightforward answer. The chapter on the hosting environment covers the trade-off.

The habit

Read the conditions. Grep your configuration for the directive. Decide whether it applies. Then patch anyway, because the next one will not have conditions you can grep for, and the version you are on is the version the next advisory will list as affected. Five CVEs sounds like a bad week for nginx. For a typical WordPress server with certbot's TLS snippet and no HTTP/3, it was a quiet one. The point of checking is knowing which.

Where this fits

Chapter 1 of the Protect My WP handbook covers the web server, including where to get nginx from and keeping it patched with unattended upgrades. Chapter 6 covers the TLS configuration, including the certbot snippet that happens to make the worst of this week's five irrelevant.

Get the book for £19.