What nginx 1.30.6 and 1.31.7 fix
Both versions came out on the same day, 14 October 2026, on the nginx.org news page. They fix five flaws in the worker process: three memory corruptions, a data injection into the body of HTTP/3 requests, and a TLS session forgery. A 1.31.8 mainline version followed on 21 October 2026; its announcement mentions no vulnerability, but it succeeds 1.31.7 and therefore contains its fixes.
On severity, two readings coexist, and they must be quoted as published. The nginx.org security advisories page rates all five flaws as "medium". The CVE records published by F5, the vendor behind nginx, give three of them a CVSS 3.1 score of 8.1. They spell out the scenario: the worker crashes and restarts, and code execution remains possible if ASLR is disabled or bypassed. All of them require a specific configuration to be exploitable. That is what makes the inventory worthwhile: on a fleet, some servers are simply not affected.
The five flaws and what exposes you
- CVE-2026-15176, alias and rewrite — heap overflow in the worker when a
locationcombinesalias,rewriteand asetorreturndirective that reads$request_filename, or when$request_filenameappears in alog_format. Vulnerable range: 0.1.29 to 1.31.6. - CVE-2026-93479, strings with variables — overflow while computing the document root or writing logs, typically a regex
mapwhose captures$1,$2are read byrootor alog_formatbefore the output variable. Vulnerable range: 1.30.0 to 1.30.5 and 1.31.2 to 1.31.6. - CVE-2026-95101, HTTP/3 request body — part of an unknown frame may be read as request body: bypass of
client_max_body_sizeor injection into the proxied request, withproxy_request_buffering on, the default value. Vulnerable range: 1.25.0 to 1.31.6. - CVE-2026-97629, TLS session tickets — with
ssl_session_cache shared:…and nossl_session_ticket_key, nginx rotates its keys itself; one of them was left uninitialized, which allows forging a session and, according to F5, bypassing client certificate verification. Vulnerable range: 1.23.2 to 1.31.6. - CVE-2026-97205, SSI with AIO — use-after-free when
aiois enabled and an SSI page containsinclude virtualcommands. Vulnerable range: 0.8.11 to 1.31.6. - Published severity — "medium" for all five on nginx.org. According to F5's CVE records, the CVSS 3.1 score is 8.1 for CVE-2026-15176, CVE-2026-93479 and CVE-2026-97205, 6.5 for CVE-2026-97629 and 5.3 for CVE-2026-95101.
Affected and fixed versions
Scroll the table
| Flaw or package | Vulnerable versions | Fixed in |
|---|---|---|
| CVE-2026-15176 — alias and rewrite | 0.1.29 to 1.31.6 | 1.30.6 and 1.31.7 |
| CVE-2026-93479 — strings with variables | 1.30.0 to 1.30.5, 1.31.2 to 1.31.6 | 1.30.6 and 1.31.7 |
| CVE-2026-95101 — HTTP/3 | 1.25.0 to 1.31.6 | 1.30.6 and 1.31.7 |
| CVE-2026-97629 — TLS tickets | 1.23.2 to 1.31.6 | 1.30.6 and 1.31.7 |
| CVE-2026-97205 — SSI with AIO | 0.8.11 to 1.31.6 | 1.30.6 and 1.31.7 |
| Debian 13 package (trixie) | Packages older than `1.26.3-3+deb13u10` | `1.26.3-3+deb13u10` (DSA-6575-1) |
| Debian 12 package (bookworm) | Marked vulnerable as of 22 October 2026 | Not published yet |
| Ubuntu packages | "Needs evaluation" as of 22 October 2026 | Not published yet |
Distro package or Docker: the version number is not enough
This is the most common objection on a mixed fleet: nginx -v shows 1.26.3 or 1.22.1, far below 1.30.6, and yet the machine may well be fixed. Distributions backport security fixes into their own branch without changing the upstream number: only the package suffix moves. Debian did this for trixie with advisory DSA-6575-1, which covers all five CVEs. Conversely, as of 22 October 2026, the Debian security tracker still marked bookworm as vulnerable, and Ubuntu showed "Needs evaluation" for all of its tracked releases.
The only reliable check is therefore the changelog of the installed package: zgrep -l CVE-2026-15176 /usr/share/doc/nginx*/changelog.Debian.gz on Debian or Ubuntu, rpm -q --changelog nginx | grep CVE-2026-15176 on RHEL, AlmaLinux or Rocky. A matching line means the fix has been backported; nothing at all means it has not been yet. For Docker, the tag is what matters: the official nginx:1.30.6 and nginx:1.31.7 images are live on Docker Hub, and an image pinned to an older tag stays vulnerable until it is replaced.
Audit a server's exposure in ten minutes
Record the version and the source
nginx -vgives the binary version. Where the package comes from decides how you update it:apt-cache policy nginxon Debian or Ubuntu (nginx.org repository or distribution)rpm -qi nginx | grep -E 'Version|Release|Vendor'on RHEL and derivatives
If nginx runs in a container:docker ps | grep -i nginx.List the compiled modules
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'http_v3|ssi|threads|file-aio'
Without--with-http_v3_module, CVE-2026-95101 does not concern you. The SSI module is built by default: only the--without-http_ssi_moduleoption excludes it.Export the effective configuration
sudo nginx -T > /root/nginx-conf.txt 2>&1nginx -Ttests the configuration and prints all of it, included files too. Query this file rather than browsing/etc/nginxby hand: one forgottenincludeis enough to miss a directive.Look for alias and $request_filename (CVE-2026-15176)
grep -nE '^\s*(alias|rewrite)\s' /root/nginx-conf.txtgrep -n 'request_filename' /root/nginx-conf.txt
You are exposed if onelocationcombinesalias,rewriteand asetorreturnthat reads$request_filename, or if alog_formatcontains that variable.Look for regex maps (CVE-2026-93479)
grep -nA8 '^\s*map ' /root/nginx-conf.txt
Spot the entries starting with~, then look for$1,$2inrootandlog_formatdirectives. This flaw only affects the 1.30 and 1.31 branches: a server on 1.28 or below is not concerned.Check HTTP/3 (CVE-2026-95101)
grep -nE 'listen\s.*quic|http3' /root/nginx-conf.txtgrep -n 'proxy_request_buffering' /root/nginx-conf.txt
HTTP/3 enabled in front of aproxy_pass, withoutproxy_request_buffering off: exposed.Check TLS tickets (CVE-2026-97629)
grep -nE 'ssl_session_cache\s.*shared|ssl_session_ticket_key|ssl_session_tickets' /root/nginx-conf.txt
Exposed ifshared:is present withoutssl_session_ticket_keyorssl_session_tickets off. The impact described by F5 mainly concerns sites that authenticate clients by certificate (ssl_verify_client).Check SSI and AIO (CVE-2026-97205)
grep -nE '^\s*(ssi|aio)\s' /root/nginx-conf.txt
Exposed ifssi onandaio(valueonorthreads) apply to the same pages, and those pages containinclude virtualcommands.
In what order to handle a fleet of servers
With these eight checks, every server lands in one of three boxes. First box: an exposure condition is present and the server receives public traffic. It gets patched today, or receives a mitigation within the hour. Reverse proxies serving HTTP/3 and sites authenticating by client certificate come first, because the described impact hits the proxied request or the authentication itself.
Second box: no condition is present, but the version is in the vulnerable range. The immediate risk is low, and the update is scheduled within the week. Configurations change, and an alias added tomorrow by a developer is enough to reopen CVE-2026-15176.
Third box: version already fixed, or a distribution package whose changelog cites the CVEs. Nothing to do, except recording the date of the check. Keep this table per client: it is also the answer to give when a client asks whether they were affected.
Update environment by environment
nginx.org repository on Debian or Ubuntu
sudo apt update && sudo apt install --only-upgrade nginx
Thennginx -vmust show 1.30.6 on the stable branch, 1.31.7 or newer on mainline.nginx.org repository on RHEL, AlmaLinux or Rocky
sudo dnf upgrade nginx
Same check withnginx -v. For both families, the repository setup is described on the nginx.org Linux packages page.Distribution package
On Debian 13,
sudo apt update && sudo apt install --only-upgrade nginxmust bring1.26.3-3+deb13u10or newer. Elsewhere, apply security updates as soon as they are released and check the changelog as shown above. If your distribution lags behind, switching to the nginx.org repository is possible; first make sure the dynamic modules you depend on exist there.Docker containers
In the compose file, pin
image: nginx:1.30.6(ornginx:stable), then:docker compose pull && docker compose up -d
An image builtFROM nginx:…must be rebuilt:docker compose build --pull && docker compose up -d.Server managed by a panel or a hosting provider
If nginx was installed by an administration panel or by your hosting provider, their update channel delivers the fix. Check
nginx -vand the package changelog after their update and, if in doubt, ask the provider on which date the fix was applied.Test the configuration
sudo nginx -t
The expected answer containssyntax is okandtest is successful. Never restart without this test: an invalid configuration leaves the service stopped.Replace the binary in memory
Updating the package does not replace the master process already running.
sudo ls -l /proc/$(cat /run/nginx.pid)/exeshows(deleted)as long as the old binary is running (adjust the PID file path).sudo systemctl restart nginxcuts traffic for a few seconds; on-the-fly replacement with theUSR2signal, documented by nginx, avoids that cut but requires a good knowledge of your systemd setup.Check, then monitor
Run
nginx -vand the/proccommand again: no more(deleted). Test a site withcurl -sI https://your-domain.com. Then add an alert on worker restarts, as in our guide proactive monitoring and alerting on a VPS.
Cannot patch today: the mitigations published by F5
F5's CVE records describe a mitigation for each of the five flaws. They remove the exposure condition without fixing the code: they are stopgap measures.
CVE-2026-15176: do not use alias in the affected location, or do not use $request_filename.
CVE-2026-93479: replace unnamed captures with named captures, such as (?<site>…), and limit their use to the block where the regex applies.
CVE-2026-95101: proxy_request_buffering off;. Upload bodies are then streamed to the application, which changes its behaviour on large files.
CVE-2026-97629: remove ssl_session_cache shared:…, or load static keys with ssl_session_ticket_key (file created by openssl rand 80 > /etc/nginx/ticket.key). Servers running ssl_session_tickets off; are not affected.
CVE-2026-97205: disable aio, or stop serving SSI pages.
Each mitigation is validated with nginx -t then systemctl reload nginx. A reload is enough here, since the binary does not change.
Detection: clues, not proof
A crashing worker leaves a line such as worker process 12345 exited on signal 11 in the error log. Count them with grep -c 'exited on signal' /var/log/nginx/error.log and compare with previous weeks. Repeated crashes on an exposed server are a clue worth investigating, not proof of compromise; their absence is not proof of safety either. General measure, outside the vendor advisory: restrict at the firewall the vhosts that do not need to be public, as detailed in our Linux VPS hardening checklist.
Troubleshooting: errors that follow the update
nginx -v shows 1.30.6, but nothing has changed. The binary on disk is new, the master process is the old one. The command ls -l /proc/<pid>/exe shows it with the (deleted) mark. Fix: restart the service, or replace it on the fly with USR2.
nginx: [emerg] "/etc/nginx/ticket.key" must be 48 or 80 bytes. The ticket key file does not have the right size, often because it was created in base64 or with a trailing newline. Fix: openssl rand 80 > /etc/nginx/ticket.key, without any encoding option, then nginx -t.
nginx is already the newest version. Your distribution's repository does not offer a fixed package yet. Fix: apply the mitigations above and follow the distribution's security tracker, or move to the nginx.org repository.
The container still answers with the old version. The image was pulled, but the container was not recreated, or the service points to a pinned tag. Fix: docker compose up -d --force-recreate, then docker compose exec <service> nginx -v.
Five flaws on twenty servers: an agency's workload
For an agency, this fix is not one command: it is a tour of the fleet. One server per client, different sources (a Debian package here, the nginx.org repository there, a Docker image elsewhere), configurations written by several people. Each machine needs the inventory, the update, the restart, the check, then the answer to the worried client.
The most durable way to reduce this workload is to reduce the number of web servers you administer yourself. With ServOrbit.com reseller hosting, your clients' sites run in cPanel accounts you manage from WHM, under your own brand: you keep the client relationship and your prices, we run the infrastructure. For machines that must stay with root access, the administration option is available on our Cloud VPS. And if you are still weighing the reverse proxy for these machines, our Caddy, Traefik and nginx comparison sets out the criteria.
