If you run nginx, 2026 has been a busy year for patching. nginx.org lists 21 security advisories carrying 2026 CVE numbers, fixed across seven releases between February and September. The newest fix shipped on September 15, 2026 in nginx 1.31.6 (mainline) and 1.30.5 (stable). If your server still reports anything older, at least one fix is missing.
This guide puts every one of those fixes in one place: which release closed which CVE, which configuration you need to be exposed, the commands to check your version and update, and one trap that catches people after they patch. Everything below comes from nginx's own advisory list and release notes, linked at the end.
Short version:
- Check with
nginx -v. You have every fix listed here on 1.31.6 or later (mainline) or 1.30.5 or later (stable). - The 1.28 branch and older only received the fixes up to March 2026. nginx.org lists the later fixes for 1.30.x and 1.31.x only, so move to one of those.
- Most of these flaws need a specific feature in your config (rewrite with captures,
mapwith regex, HTTP/3, SSI, WebDAV and so on). That tells you how urgent each one is for you, but it is not a reason to skip the upgrade. - After you upgrade, confirm the running worker processes use the new binary. A package upgrade does not always replace a process that is already running.
The versions you need
| Release date | Mainline | Stable | CVEs fixed |
|---|---|---|---|
| September 15, 2026 | 1.31.6 | 1.30.5 | CVE-2026-90439 |
| July 15, 2026 | 1.31.3 | 1.30.4 | CVE-2026-42533, CVE-2026-60005, CVE-2026-56434 |
| June 17, 2026 | 1.31.2 | 1.30.3 | CVE-2026-42530 (mainline only), CVE-2026-42055, CVE-2026-48142 |
| May 22, 2026 | 1.31.1 | 1.30.2 | CVE-2026-9256 |
| May 13, 2026 | 1.31.0 | 1.30.1 | CVE-2026-42926, CVE-2026-42945, CVE-2026-42946, CVE-2026-42934, CVE-2026-40460, CVE-2026-40701 |
| March 24, 2026 | 1.29.7 | 1.28.3 | CVE-2026-27654, CVE-2026-27784, CVE-2026-32647, CVE-2026-27651, CVE-2026-28753, CVE-2026-28755 |
| February 4, 2026 | 1.29.5 | 1.28.2 | CVE-2026-1642 |
The target is the top row. Each release includes all earlier fixes, so 1.31.6 or 1.30.5 covers the whole table. (CVE-2026-42530 only ever affected mainline 1.31.0 and 1.31.1, so it was fixed in 1.31.2 and has no stable fix.) Releases 1.31.4 (August 19) and 1.31.5 (September 2) carry no security fixes, which means a server on 1.31.4 or 1.31.5 is missing the September fix.
The newest fix: CVE-2026-90439 (HTTP/3)
The September 15 release fixes a heap buffer overflow in a worker process that can occur "under certain configurations when using HTTP/3 with OpenSSL 3.5.0 and earlier", according to the nginx release notes. nginx.org labels it medium and lists nginx 1.29.2 through 1.31.5 as vulnerable.
You are in the exposed group if two things are true: nginx is built against OpenSSL 3.5.0 or earlier, and you serve HTTP/3 (a listen ... quic line). Check both:
nginx -V 2>&1 | grep -E "nginx version|built with OpenSSL"
nginx -T 2>/dev/null | grep -nE "quic|http3"If the second command prints nothing, you do not serve HTTP/3 and this particular flaw does not apply to your configuration. Upgrade anyway, because the same release train carries the other fixes.
All 21 advisories, with what you need to be exposed
The "Exposed when" column paraphrases the release notes. nginx's own severity label is in the last column; where the release note mentions possible code execution, we say so, because the label alone understates it.
| CVE | Component | Exposed when | nginx severity |
|---|---|---|---|
| CVE-2026-90439 | HTTP/3 | HTTP/3 with OpenSSL 3.5.0 and earlier; heap overflow in a worker | Medium |
| CVE-2026-42533 | map + regex | A map variable used in a string after a regex capture, or a non-cacheable variable in a string; heap overflow | Major |
| CVE-2026-60005 | slice module | Unnamed regex captures with slice or background cache update; memory disclosure or worker crash | Medium |
| CVE-2026-56434 | SSI module | Server-side includes processing a crafted proxied backend response; use-after-free | Medium |
| CVE-2026-42530 | HTTP/3 | HTTP/3 on 1.31.0 or 1.31.1 only; crafted QUIC session; use-after-free | Major |
| CVE-2026-42055 | proxy to HTTP/2 or gRPC | ignore_invalid_headers off plus large large_client_header_buffers, proxying to an HTTP/2 or gRPC backend; heap overflow | Medium |
| CVE-2026-48142 | charset module | charset_map decoding from UTF-8; limited memory disclosure or crash | Low |
| CVE-2026-9256 | rewrite module | Overlapping captures in rewrite rules; heap overflow, "potentially resulting in arbitrary code execution" | Medium |
| CVE-2026-42945 | rewrite module | A crafted request handled by the rewrite module; heap overflow, "potentially resulting in arbitrary code execution" | Medium |
| CVE-2026-42926 | proxy module | proxy_set_body to an HTTP/2 backend; data injection | Medium |
| CVE-2026-42946 | SCGI / uWSGI | Crafted backend response; memory disclosure or crash | Medium |
| CVE-2026-42934 | charset module | charset_map decoding from UTF-8; limited memory disclosure or crash | Low |
| CVE-2026-40460 | HTTP/3 | QUIC connection migration; client address spoofing | Medium |
| CVE-2026-40701 | OCSP resolver | ssl_ocsp in use; use-after-free while processing a DNS response | Medium |
| CVE-2026-27654 | WebDAV | COPY or MOVE in a location with alias; path can leave the document root | Medium |
| CVE-2026-27784 | mp4 module | Crafted mp4 file on 32-bit platforms | Medium |
| CVE-2026-32647 | mp4 module | Crafted mp4 file | Medium |
| CVE-2026-27651 | mail proxy | CRAM-MD5 or APOP with authentication retry enabled; worker crash | Low |
| CVE-2026-28753 | mail proxy | PTR DNS records used to inject data into auth_http requests and the XCLIENT command | Medium |
| CVE-2026-28755 | stream + OCSP | TLS handshake can succeed although OCSP rejected the client certificate | Medium |
| CVE-2026-1642 | SSL upstream | An attacker can inject plain text into a response from an SSL backend | Medium |
The two flaws nginx rates major are CVE-2026-42533 (a map and regex pattern that is common in real configurations) and CVE-2026-42530 (HTTP/3 on two early 1.31 releases only). The two rewrite-module flaws deserve attention too: rewrite rules with captures exist on almost every WordPress and framework vhost, and the release notes say code execution is possible.
Find out what you actually use
One command lists the features from the table that appear in your effective configuration, including every included file:
nginx -T 2>/dev/null | grep -nE "^\s*(rewrite|map|slice|ssi|charset_map|ssl_ocsp|proxy_set_body|dav_methods|mp4|grpc_pass|mail|stream)\b|quic|http3"Treat the output as a to-do list for reading, not as a verdict. A rewrite line is not automatically vulnerable, and an empty result does not make an old version safe, because configuration changes later. The reliable answer is the version.
Check your version and update
First, what you have:
nginx -vThen update through the same channel you installed from.
nginx.org packages on Debian or Ubuntu:
sudo apt update
sudo apt install --only-upgrade nginx
sudo nginx -tnginx.org packages on RHEL, Rocky or AlmaLinux:
sudo dnf upgrade nginx
sudo nginx -tDistribution packages need a different check. Distributions often keep an older version number and copy the security fix into it, so nginx -v can look out of date on a patched machine. Read the package changelog instead:
# Debian / Ubuntu
apt changelog nginx | grep -i "CVE-2026" | head -30
# RHEL family
rpm -q --changelog nginx | grep -i "CVE-2026" | head -30If the CVEs from the table are not mentioned and the distribution has no update for you, switch to the nginx.org repository for the 1.30 stable branch, which is a normal supported path.
The trap after patching: the old binary is still running
Installing a new package puts a new file on disk. It does not change the worker processes that were already started from the old file. Some packages upgrade the running binary for you and some do not, so verify:
ls -l /proc/$(cat /run/nginx.pid)/exeIf the output ends in (deleted), the master process is still running the old, replaced binary. Restart nginx during a quiet moment (sudo systemctl restart nginx) after nginx -t passes. A plain reload re-reads configuration but is not the step that guarantees a new binary, so do not rely on it alone. Then run nginx -v and the /proc check once more.
Is any of this being exploited?
The nginx advisories and release notes we read do not say that any of these flaws are exploited in the wild, and we did not find a statement either way in them. That is the absence of a claim, not a clean bill of health. Check the US CISA Known Exploited Vulnerabilities catalog for the CVE numbers above before you decide how fast to move, and patch the two major ones first.
Whatever the answer is today, internet-facing web servers are scanned constantly. A server that is months behind on the web server itself is exactly what automated scanners are built to find.
Make the next one boring
- Pick one branch and stay on it. Use the 1.30.x stable branch unless you need a mainline feature, and follow its point releases (every point release from 1.30.1 to 1.30.5 carried security fixes this year).
- Turn off what you do not use. Several flaws above only matter if a module is in play. Do not enable HTTP/3, WebDAV, SSI or mp4 streaming on a vhost that does not need them.
- Test before you restart.
nginx -tcatches configuration errors; keep the previous package version available in case you need to roll back. - Put the checks on a schedule. A weekly job that prints
nginx -vand the pending security updates is the difference between knowing and finding out from a scan. - Keep off-server backups and test a restore, so a bad day is a rebuild and not a crisis.
If you would rather not own patching
Keeping a web server current is routine work, and it is easy to let slip when it is nobody's job. On a TOSHOST Managed VPS, our engineers apply OS and security updates, monitor the server around the clock and keep off-site backups, so a release like 1.31.6 is handled for you. If you already have a server and want it checked, our team can review the version, the modules in use and the exposure above and tell you what to change.
Already worried that something got in before you patched? Our security and malware cleanup services cover a single hacked site up to a whole server.
Sources
- nginx security advisories: the list of CVEs, severities, vulnerable and fixed versions.
- nginx CHANGES (mainline) and CHANGES-1.30 (stable): release dates and the description of each security fix.
- The per-CVE advisory pages that nginx.org links to, for example CVE-2026-90439, CVE-2026-42533 and CVE-2026-9256.
Last updated October 7, 2026. Version numbers and dates are taken from the nginx.org pages above as of that date; if nginx publishes a newer release, that page is the authority.
Frequently asked questions
What is the latest safe nginx version in 2026?
As of October 7, 2026, nginx 1.31.6 on the mainline branch and 1.30.5 on the stable branch, both released on September 15, 2026. Either one includes every security fix listed on nginx.org for 2026.
How many nginx vulnerabilities were fixed in 2026?
nginx.org lists 21 advisories with 2026 CVE numbers, fixed across releases from February 4 to September 15, 2026. The two it rates major are CVE-2026-42533 and CVE-2026-42530.
Is nginx 1.31.4 or 1.31.5 vulnerable?
Both are missing the September fix for CVE-2026-90439, which affects 1.29.2 through 1.31.5. It only matters if you serve HTTP/3 and nginx is built with OpenSSL 3.5.0 or earlier, but upgrading to 1.31.6 is the simple answer.
How do I check my nginx version?
Run nginx -v for the version, or nginx -V to also see the OpenSSL it was built with. On distribution packages, read the package changelog for the CVE numbers, because the fix may be backported into an older-looking version number.
Do I have to restart nginx after upgrading?
Verify that the running process uses the new binary: run ls -l /proc/$(cat /run/nginx.pid)/exe. If the path ends in (deleted), restart nginx after nginx -t passes. A reload alone is not a reliable way to switch binaries.
Which nginx flaws are the most serious?
nginx labels CVE-2026-42533 (map with regex) and CVE-2026-42530 (HTTP/3 use-after-free on 1.31.0 and 1.31.1) as major. The two rewrite module flaws, CVE-2026-9256 and CVE-2026-42945, are labelled medium, but the release notes say they could potentially lead to arbitrary code execution.
Does Toshost patch nginx for me?
On a Toshost Managed VPS our engineers apply operating system and security updates and monitor the server, so you do not have to track releases yourself. Unmanaged servers are yours to patch.
