Is your nginx patched? Check 1.30.6 fixes on Ubuntu and Debian

If you run nginx from Ubuntu or Debian packages, the number that nginx -v prints will not tell you whether you are patched. You need to compare your full package version with the fixed version on your distribution's security tracker, then upgrade and restart so the new binary is the one serving traffic.

Here is the twist. On 14 October 2026 nginx released 1.30.6 stable and 1.31.7 mainline with five security fixes, yet a fully patched Ubuntu 22.04 server still reports nginx 1.18.0. Meanwhile, at the time of writing (5 November 2026), Debian's tracker still marks the bookworm package as vulnerable to CVE-2026-15176, even in the security archive.

By the end of this guide you will know which nginx you actually run, whether your config uses the risky features, how to patch it on Ubuntu or Debian, and how to prove the fixed binary is live.

What this nginx security update actually is

nginx publishes two branches. Stable (1.30.x) gets only important fixes, while mainline (1.31.x) gets new features too. On 14 October 2026 both branches got the same five security fixes, and mainline 1.31.8 followed on 21 October 2026.

Here is what each fix covers, in plain words, from the official 1.30.6 changelog:

• CVE-2026-15176: a buffer overflow (writing past the end of a memory area) in a worker process when alias is used, the URI was changed by rewrite, and the result was then mapped to a file path.
• CVE-2026-93479: a buffer overflow while evaluating string expressions with variables, which affected the document root calculation and request logging.
• CVE-2026-95101: with HTTP/3, part of an unknown frame might be treated as the request body, which could bypass the client_max_body_size limit or inject data into a proxied request.
• CVE-2026-97629: with TLS session ticket key rotation, one of the keys was left uninitialized, which might allow someone to forge a session.
• CVE-2026-97205: a use-after-free (code using memory that was already given back) with asynchronous file I/O (AIO) when an SSI page has include virtual commands.

The nginx security advisories page rates all five as medium. The version ranges are wide: CVE-2026-15176 affects 0.1.29 to 1.31.6, and CVE-2026-97629 affects 1.23.2 to 1.31.6. Fixed versions are 1.30.6 and later on stable, and 1.31.7 and later on mainline.

Why this matters: Ubuntu's page for CVE-2026-15176 gives it a CVSS v3.1 score of 8.1 and describes a heap buffer overflow that restarts the worker, with code execution possible where ASLR (memory layout randomisation) is disabled or can be bypassed. That is worth an evening of your time.

Think of your distro package like a car model year. A 2022 car can have the 2026 safety recall fitted at the garage. The badge still says 2022, but the part is new. Ubuntu and Debian do exactly this: they copy the fix into the old version and add a suffix such as ubuntu14.22 or deb13u10. Debian's security FAQ says it plainly: they backport security fixes to the version shipped in the stable release instead of moving to a new upstream version.

So the question is never "do I have 1.30.6?". The question is "do I have the package version my distribution says is fixed?".

Before you start

• Root or sudo access over SSH to the server.
• About 20 to 30 minutes per server, plus a quiet window for a restart.
• Risk level: low to medium. A package upgrade and restart drops in-flight connections for a moment. Switching to the nginx.org repository is a bigger change.
• Know who manages nginx. If cPanel, Plesk or another panel installed it, follow the panel's update path instead. Our guide on checking if cPanel or Plesk is patched on a VPS covers that side.
• A backup of /etc/nginx (Step 1 below).
• A second SSH session open, so you can fix things if a restart fails.

Find out what you actually run

Step 1: Back up the configuration directory

Before you touch anything, take a copy of the whole nginx config. This command creates a dated, compressed archive in root's home directory.

sudo tar -czf /root/nginx-backup-$(date +%F).tar.gz /etc/nginx

Check that the archive exists and is not tiny with ls -lh /root/nginx-backup-*.

Quick tip: if you plan to switch repositories later, keep this archive somewhere off the server too. A backup on the same disk does not help if the disk is the problem.

Step 2: Print the version and build flags

These two commands print the version, then the version plus compiler and configure parameters, as documented on the nginx command-line page.

nginx -v
nginx -V

The first command shows the base version, for example 1.24.0 on an Ubuntu 24.04 package. The -V output is a long line of --with-... flags. To check quickly whether HTTP/3 support was compiled in, this filters that line for the module name.

nginx -V 2>&1 | tr ' ' '\n' | grep 'http_v3'

If --with-http_v3_module shows up, your binary can speak HTTP/3. The nginx docs say this module is not built by default, so a custom build only has it if someone asked for it. If there is no match at all, the HTTP/3 bug cannot reach you through this binary.

Heads up: also run command -v nginx. If it prints /usr/local/sbin/nginx or similar, someone compiled nginx from source, and apt upgrades will not touch it.

Step 3: Check the package version and where it came from

This command shows the installed version, the newest candidate apt can see, and which repository each version comes from.

apt-cache policy nginx

Made-up example text of what you might see on Ubuntu 24.04 (your exact lines will differ):

nginx:
  Installed: 1.24.0-2ubuntu7.18
  Candidate: 1.24.0-2ubuntu7.19
  Version table:
     1.24.0-2ubuntu7.19 500
        500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
 *** 1.24.0-2ubuntu7.18 100
        100 /var/lib/dpkg/status

If Installed and Candidate differ, an update is waiting. On Ubuntu, packages such as nginx-core, nginx-full, nginx-light and nginx-extras share the same version, so dpkg -l 'nginx*' is a useful second look.

Step 4: Compare with the fixed version on the tracker

Now compare your Installed value with the official fixed versions. These are the values I read on 5 November 2026.

Ubuntu, from the Ubuntu CVE-2026-15176 page and notice USN-8955-1 (published 26 October 2026, covering all five CVEs):

• 26.10 stonking: fixed in 1.30.4-7ubuntu1.1
• 26.04 LTS resolute: fixed in 1.28.3-2ubuntu1.12
• 24.04 LTS noble: fixed in 1.24.0-2ubuntu7.19
• 22.04 LTS jammy: fixed in 1.18.0-6ubuntu14.22
• 20.04 LTS focal and older: "Needs evaluation", with no fixed version listed

Ubuntu's notice adds that CVE-2026-95101 affects only 26.04 LTS and 26.10, and CVE-2026-97629 only 24.04 LTS and later.

Debian, from the Debian security tracker for CVE-2026-15176:

• trixie (13): fixed in 1.26.3-3+deb13u10 from the security archive, via DSA-6575-1
• bookworm (12): 1.22.1-9+deb12u10 in the security archive is still marked vulnerable, with no fixed bookworm version listed
• forky and sid: fixed in 1.30.6-2

If your version is equal to or higher than the fixed one, you have the backported fix for that CVE. Debian's FAQ also suggests reading the package changelog. This command downloads the changelog for your installed version so you can search it for the CVE number.

apt-get changelog nginx | grep -n 'CVE-2026-15176'

A matching line means the maintainers say the fix is in. No line on a version below the fixed one means you still need to upgrade.

Made-up example: Priya looks after twelve client VPSes for her agency. Eleven are Ubuntu 24.04 and show 1.24.0-2ubuntu7.19 after a normal update. The twelfth is an old Debian 12 box showing 1.22.1-9+deb12u10. The u10 suffix looks fresh, so she almost ticks it off. The tracker says that exact version is still vulnerable, so it goes on her "needs a plan" list instead.

Check whether your config uses the risky features

Every one of these bugs needs a particular feature to be in use. Knowing which ones you use tells you how urgent each server is, and what to do if a fixed package is not available yet.

Step 5: Search the config for risky patterns

This one command searches every file under /etc/nginx for all the patterns that matter here, and prints the file name and line number of each match.

sudo grep -RnE '^\s*(alias|rewrite|ssl_session_ticket_key|aio|ssi)\s|listen\s.*\bquic\b|request_filename' /etc/nginx/

If your config includes files from outside /etc/nginx, use sudo nginx -T instead. It tests the config and also dumps every configuration file to the screen, so you can pipe it into the same grep -nE pattern.

Made-up example output (not from a real server):

/etc/nginx/sites-enabled/example.com:14:    listen 443 quic reuseport;
/etc/nginx/sites-enabled/example.com:32:        rewrite ^/media/old/(.*)$ /media/$1 last;
/etc/nginx/sites-enabled/example.com:33:        alias /var/www/example.com/assets/;
/etc/nginx/conf.d/tls.conf:6:    ssl_session_ticket_key /etc/nginx/keys/current.key;
/etc/nginx/conf.d/tls.conf:7:    ssl_session_ticket_key /etc/nginx/keys/previous.key;

Here is how to read the results:

• alias near rewrite, especially with $request_filename in a set, return or log_format: this is the pattern behind CVE-2026-15176. Debian's tracker description names set or return with $request_filename, and $request_filename in an access log format.
• Two or more ssl_session_ticket_key lines: this is key rotation, the setup in CVE-2026-97629. The nginx docs show exactly this pattern with current.key and previous.key.
• listen ... quic: you serve HTTP/3, so CVE-2026-95101 applies.
• ssi on together with aio (or aio threads): the condition for CVE-2026-97205, if your SSI pages use include virtual.

Why this matters: no matches does not mean "skip the update". CVE-2026-93479 sits in general string expression handling on 1.30.x and 1.31.x, and future bugs will not care which features you grep for. Patch anyway; use the grep to set priority.

Patch it

Step 6a: Upgrade through your distribution (Ubuntu, Debian trixie)

This is the right path for most people. First refresh the package lists, then upgrade only nginx and its sibling packages without installing anything new.

sudo apt update
sudo apt install --only-upgrade nginx nginx-core

The apt-get manual describes --only-upgrade as upgrading what is installed without installing new packages, so names you do not have are just skipped. If you use nginx-full, nginx-light or nginx-extras, add those names too. Afterwards, apt-cache policy nginx should show Installed equal to the fixed version from Step 4.

Quick tip: Ubuntu's notice says a standard system update makes all the needed changes. If you are happy to update everything, sudo apt upgrade is fine too.

Step 6b: Use the official nginx.org stable repository (bookworm, or if you want 1.30.6)

If you are on Debian 12 and cannot wait, or you simply want upstream stable, the nginx.org repository gives you 1.30.x builds. At the time of writing (5 November 2026), the nginx.org Linux packages page lists Debian 12 bookworm and 13 trixie, plus Ubuntu 22.04, 24.04 and 26.04, on x86_64 and arm64.

Heads up: this replaces the distro package with a different build. Module sets and file layout can differ, so test on a staging copy first, compare nginx -V before and after, and keep your Step 1 backup close.

These are the official steps for Debian. First install the prerequisites.

sudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring

Next, download the nginx signing key and store it as an apt keyring.

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

Then check that the key file has the right fingerprint.

gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg

The output must contain 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62. If it does not, stop and delete the file. Now add the stable repository.

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

This pin tells apt to prefer nginx.org packages over the distribution's own.

echo -e "Package: *\nPin: origin nginx.org\nPin: release o=nginx\nPin-Priority: 900\n" | sudo tee /etc/apt/preferences.d/99nginx

Finally, refresh and install.

sudo apt update
sudo apt install nginx

On Ubuntu the steps are the same with two changes: install ubuntu-keyring instead of debian-archive-keyring, and use https://nginx.org/packages/ubuntu in the repository line. After this, apt-cache policy nginx should show a 1.30.x candidate from nginx.org with priority 900.

Step 6c: Reduce exposure while you wait (bookworm without a repo switch)

If you must stay on the Debian 12 package for now, these changes remove the conditions the changelog describes. They are a stopgap, not a fix.

• For alias locations with rewrite: where the location matches the end of the alias path, the nginx docs recommend root instead of alias. Also remove $request_filename from set, return and log_format lines in those locations.
• For session ticket rotation: keep a single ssl_session_ticket_key line, or set ssl_session_tickets off; until patched. The default is on, and without a key file nginx uses a random key.
• For HTTP/3: remove the listen ... quic lines if you do not need HTTP/3.
• For SSI with AIO: set aio off; (the default) in locations that use ssi on.

This is the minimal alias to root swap from the nginx docs, for a location whose name matches the last part of the path.

location /images/ {
    root /data/w3;
}

Make the new binary run

Step 7: Test the config, then restart

First check the configuration. nginx -t checks syntax and tries to open the files the config refers to.

sudo nginx -t

You want a message saying the syntax is ok and the test is successful. Then restart the service so the new binary is loaded.

sudo systemctl restart nginx

Why a restart and not a reload: the nginx control docs describe a reload (nginx -s reload, or the HUP signal) as re-reading the configuration and starting new workers with it. Replacing the executable is a separate procedure, upgrading on the fly with the USR2 signal, so a full restart is the simple way to be sure the new binary runs. On most single VPSes, a restart takes a second or two and is the simpler choice.

Step 8: Re-check the version

Run the version and package checks again.

nginx -v
apt-cache policy nginx
systemctl status nginx --no-pager

apt-cache policy should show the fixed version as Installed. In systemctl status, the line that says when the service became active should show a time after your upgrade. If it is older, the old binary is still in memory, so restart again.

How to check it worked

• apt-cache policy nginx: Installed is equal to or higher than the fixed version for your release from Step 4.
• apt-get changelog nginx | grep CVE-2026-15176: returns at least one line on a distro package.
• nginx -v: on the nginx.org repo it shows nginx/1.30.6 or later. On a distro package it shows the distro base version, which is expected.
• systemctl status nginx --no-pager: active, with a start time after the upgrade.
• curl -I https://example.com: returns your normal status line, such as HTTP/2 200, so the site is still up.

While you are in there, it is a good moment to look at your TLS settings. Our guide on checking and enabling TLS 1.3 on Apache and nginx pairs well with the session ticket changes above.

Troubleshooting

apt says nginx is already the newest version

Symptom: apt install --only-upgrade nginx changes nothing, but your version is below the fixed one. Likely cause: you skipped apt update, or the security repository (noble-security, trixie-security) is missing from your sources. Fix: run sudo apt update, then check apt-cache policy nginx lists a security source. If not, restore the default security line for your release.

nginx -v still shows the old version after the upgrade

Symptom: the package is new but the reported version or behaviour is old. Likely cause: you only reloaded, or there is a second nginx binary earlier in your PATH. Fix: run command -v nginx and sudo systemctl restart nginx. If the path is under /usr/local, that build came from source and needs its own rebuild with 1.30.6.

Debian 12 still shows vulnerable after updating

Symptom: you are on 1.22.1-9+deb12u10 and the tracker still says vulnerable. Likely cause: at the time of writing (5 November 2026), Debian has not listed a fixed bookworm version. Fix: switch to the nginx.org repository (Step 6b), apply the stopgaps in Step 6c, or plan the move to Debian 13. Recheck the tracker page weekly.

The nginx.org package is not chosen after adding the repo

Symptom: apt-cache policy nginx still prefers the distro version. Likely cause: the pin file /etc/apt/preferences.d/99nginx is missing or has a typo, or lsb_release -cs returned a codename nginx.org does not build for. Fix: recreate the pin file exactly, run sudo apt update, and confirm the nginx.org source shows priority 900.

The config test fails after switching to nginx.org packages

Symptom: nginx -t reports an unknown directive or a missing file. Likely cause: the new build has a different module set or include layout from the distro build. Fix: compare nginx -V from before and after, restore your config from the Step 1 backup if needed, and rebuild your includes on staging before trying production again.

Ubuntu 20.04 shows "Needs evaluation"

Symptom: focal and older releases have no fixed version on the Ubuntu page. Likely cause: Ubuntu lists those releases as needs evaluation for this CVE, and nginx.org does not list focal as a supported platform either. Fix: plan an OS upgrade to 22.04 or later, and ask your host or Canonical about extended support for that release.

Pro tips

• Make patch checks a habit. A five-line script that prints apt-cache policy nginx for each server saves agency admins a lot of clicking.
• After patching, run the response header check from our guide on security headers for Apache and nginx, since config edits are a common moment for headers to drop out.
• If you serve many sites through one nginx, treat the restart as a change: announce it, do it in a quiet hour, and watch the nginx error log for a few minutes afterwards.
• Ask your host or a developer for help if nginx was installed by a panel, compiled from source, or sits behind a load balancer you do not control.

The one message worth forwarding

"Hi, nginx released security fixes on 14 October 2026 (stable 1.30.6, five CVEs including CVE-2026-15176). Can you check our servers with apt-cache policy nginx and compare against the Ubuntu or Debian security tracker fixed version, then restart nginx so the new binary runs? Note Debian 12 bookworm is still listed as vulnerable, so those servers need the nginx.org repo or a mitigation plan."

Your distro version number is a model year, not a recall record, so always check the tracker, then restart.