The nginx project has released version 1.30.6 on the stable branch and 1.31.7 on the mainline branch. Together they fix five vulnerabilities in the web server itself. A companion release, njs 1.0.2, fixes two more issues in the nginx JavaScript module. The nginx team rates all five server bugs as medium severity, and there are no public reports of them being exploited. Even so, nginx runs a large share of the web as a server, reverse proxy and load balancer, and some of the affected version ranges go back many years. Treat this as a routine update, but do it soon: schedule it for this week rather than waiting for next quarter.
The five nginx fixes at a glance
Each issue depends on a particular feature, so you can work out quickly how exposed your servers are. The table below is based on the nginx security advisories page.
| CVE | Issue | Triggered by | Vulnerable versions |
|---|---|---|---|
| CVE-2026-15176 | Buffer overflow | alias used with rewrite | 0.1.29 to 1.31.6 |
| CVE-2026-93479 | Buffer overflow | Evaluating string expressions that contain variables | 1.30.0 to 1.30.5, 1.31.2 to 1.31.6 |
| CVE-2026-95101 | Request body injection | HTTP/3 | 1.25.0 to 1.31.6 |
| CVE-2026-97629 | Session forgery | TLS session ticket key rotation | 1.23.2 to 1.31.6 |
| CVE-2026-97205 | Use-after-free | ngx_http_ssi_module with AIO | 0.8.11 to 1.31.6 |
All five are fixed in 1.30.6 and later on the stable branch and in 1.31.7 and later on mainline. Pay attention to the version ranges. The SSI and AIO bug goes back to 0.8.11 and the alias bug to 0.1.29, so an old server that has run quietly for years is still affected.
njs 1.0.2
If you load the njs module to run scripts inside nginx, version 1.0.2 fixes two problems. The first is memory exhaustion when parsing malformed XML (CVE-2026-101025). The second is inconsistent XML attribute values that could affect signed XML validation (CVE-2026-101019). Check the second one carefully if any of your njs scripts verify XML signatures, because signature checks are exactly where you cannot afford ambiguity.
Check which features your servers use
Check the version first. Then dump the full running configuration, including every included file, and search it for the features named in the advisories:
nginx -v
sudo nginx -T 2>/dev/null | grep -nE 'alias|rewrite|ssi on|aio|ssl_session_ticket_key|quic|http3'How to read the matches:
- alias and rewrite in the same location block point to CVE-2026-15176.
- ssi on together with aio on or aio threads points to CVE-2026-97205.
- Several ssl_session_ticket_key lines usually mean you rotate ticket keys, which is the setup behind CVE-2026-97629.
- A quic parameter on a listen directive, or http3 on, means you serve HTTP/3 and are exposed to CVE-2026-95101.
No matches is not a reason to skip the update. CVE-2026-93479 involves string expressions that contain variables, and almost every real configuration uses them, for example in proxy_set_header or return directives. If you run 1.30.0 to 1.30.5 or 1.31.2 to 1.31.6, assume you are affected.
How to upgrade
Official nginx.org packages
If you installed nginx from the nginx.org repository, the new builds come through your normal package manager.
Debian and Ubuntu:
sudo apt update
sudo apt install --only-upgrade nginxRHEL, AlmaLinux and Rocky Linux:
sudo dnf upgrade nginxDistribution packages, control panels and containers
Debian, Ubuntu, RHEL and their derivatives ship their own nginx builds. They usually backport security fixes without changing to the upstream version number, so a patched package may not report 1.30.6. Look up the CVE IDs above in your distribution’s security tracker and install the update once it is published. On cPanel servers that use the ea-nginx package, and on other control panels, update through the panel’s own packages instead of mixing in upstream builds. For containers, pull the updated official image, rebuild any images based on it and redeploy.
Test, restart and confirm
sudo nginx -t
sudo systemctl restart nginx
nginx -v
ps -o pid,lstart,cmd -C nginxA full restart makes sure the new binary is the one serving traffic, and the process start times from ps confirm it. Third-party dynamic modules must be rebuilt for the new version, and nginx -t will reject a module compiled for the old one. Rebuild them before you restart, not after.
Stopgaps if you cannot patch today
- Remove the quic listeners to stop serving HTTP/3. Clients will fall back to HTTP/2 or HTTP/1.1.
- Turn off aio in locations that use SSI.
- Set ssl_session_tickets off. Clients can still resume sessions through ssl_session_cache if you have it configured.
- Restructure location blocks so alias and rewrite are not used together, for example by switching to root where the paths allow it.
These steps reduce exposure to individual bugs but do nothing about the string expression overflow, so they cannot replace the update.
How TechProvidence can help
TechProvidence manages nginx, Apache and cPanel servers for businesses that would rather not track every security release themselves. We can audit your configuration against these advisories, roll out the update in a planned window, rebuild custom modules and confirm that the patched version is the one actually serving traffic. If you would like us to handle it, contact us.
Source: nginx.org news
