nginx has five new security fixes. Here's whether you need to rush

If your website or web app runs on a Linux server, there's a fair chance nginx is the bit that answers when someone visits it. On 14 October the nginx project released new versions with fixes for five security flaws. You should update this month, and for some setups this week.

The nginx announcement doesn't mention any attacks, and the nginx team rates all five as medium. So this isn't a drop-everything job like yesterday's Bricksforge flaw. But it's worth ten minutes to see where you stand.

What happened

The project's announcement says versions 1.30.6 (stable) and 1.31.7 (mainline) fix five problems. The security advisories page lists every version from 1.31.6 down as affected by at least one of them, and some go back a very long way.

In plain English, here's what each one needs before it can bite, going by the nginx changelog:

• alias with rewrite. A memory overflow in the worker process when the alias setting is used on an address that a rewrite rule has changed. Debian's tracker entry says that, in certain setups, a stranger can trigger it with crafted requests, causing a restart, and in some cases it may let them run code.
• String expressions with variables. Another memory overflow, affecting how nginx works out the document root and writes its logs. This one only affects recent versions (1.30.0 onwards).
• HTTP/3. If you've switched HTTP/3 on, part of a request could be treated as the body. That might get round your upload size limit or slip extra data into what's passed to your app.
• TLS session tickets. A setting used to speed up repeat HTTPS connections left one of its keys uninitialised, which might allow a session to be forged. Debian's entry for this one says it matters most if you use client certificates to control who gets in.
• SSI with AIO. A memory error in an unusual combination: server-side includes plus asynchronous file reading.

The same day, the project also released njs 1.0.2, an optional add-on for nginx, with two fixes of its own.

Does it affect you?

First, find out whether you run nginx at all. On the server, this tells you the version:

nginx -v

If that says "command not found", you're probably on Apache or something else, and this post isn't for you. If you're on shared hosting or a managed platform, your host looks after nginx, and there's nothing for you to do.

Next, work out where your nginx came from. On Debian or Ubuntu:

apt-cache policy nginx

If the version comes from nginx.org, you can update to 1.30.6 or 1.31.7 now. If it comes from your Linux distribution, the version number will look older, because distributions copy fixes into their own builds rather than moving to the newest release. So don't panic if it says 1.22 or 1.26. What matters is whether your distribution has shipped the fix yet.

When I checked Debian's tracker on 16 October, the stable releases (trixie and bookworm) were still listed as vulnerable to the two flaws I looked up (alias and session tickets), with only the development version (sid) fixed. That will change over the next few days. For Ubuntu, search for nginx on Ubuntu's security pages.

Finally, see which of the risky settings you actually use. This prints your whole nginx setup and picks out the relevant lines:

sudo nginx -T | grep -E "alias|rewrite|http3|ssl_session|ssi |aio"

If nothing comes back, your exposure is low. If you see alias and rewrite together, or http3 on, move this up your list.

What to do this week

1. If you installed nginx from nginx.org, update now. On Debian or Ubuntu that's sudo apt update && sudo apt install nginx. Then run sudo nginx -t to check the config and sudo systemctl reload nginx to load it.

2. If you use your distribution's nginx, keep an eye out for a security update over the next week or so and install it as soon as it arrives. If you have automatic security updates switched on (unattended-upgrades on Debian and Ubuntu), it will usually arrive by itself. Do check nginx actually restarted afterwards, though. An updated package doesn't help while the old version is still running.

3. If you use HTTP/3 and have no fix available yet, consider switching it off for now. Visitors fall back to HTTP/2 without noticing.

4. If you use njs, update it to 1.0.2 alongside nginx.

5. Look at your logs. A few of these flaws crash the worker process. If your nginx error log starts showing worker processes exiting unexpectedly, and you've not changed anything, treat that as worth a closer look.

The bigger point

This is a fairly ordinary week for a web server. It doesn't need heroics. It needs someone to notice, check which settings apply, install the update when it lands and confirm the server restarted.

If nobody in your business is going to do that, that's what a support retainer is for. I keep your servers updated, watch for problems, and tell you about them in plain English.