

nginx has been running on your server for months, probably years. You haven’t touched its config. It just works. Three days ago it got six security fixes in one release, and every one of them is worth at least a glance.
The release#
nginx 1.28.x is the stable branch. When it ships security fixes, they’re deliberate backports from mainline, not experimental changes. Version 1.28.3 came out March 24, 2026. If you’re on Ubuntu and haven’t upgraded yet, apt upgrade nginx is all it takes.
Six CVEs at a glance#
| CVE | Severity | CVSS 4.0 | What’s vulnerable | Impact |
|---|---|---|---|---|
| CVE-2026-27654 ↗ | High | 8.8 | alias + WebDAV COPY/MOVE | Path escape outside document root |
| CVE-2026-27651 ↗ | High | 8.7 | CRAM-MD5/APOP mail auth with retry | Worker process segfault |
| CVE-2026-27784 ↗ | High | 8.5 | MP4 module, 32-bit platforms | Worker process crash |
| CVE-2026-32647 ↗ | High | 8.5 | MP4 module, all platforms | Worker process crash |
| CVE-2026-28755 ↗ | Medium | 5.3 | OCSP in stream module | Revoked client cert accepted |
| CVE-2026-28753 ↗ | Medium | 6.3 | PTR DNS records in auth_http/SMTP proxy | Data injection into backend requests |
Breaking each one down#
CVE-2026-27654 ↗ l ↗ives in how nginx handles the alias directive when WebDAV methods (COPY, MOVE) are enabled. An attacker can craft a request that shifts the source or destination path outside the document root. The alias directive has a long history of path-handling edge cases in nginx. No config change is needed to get the fix, just the upgrade. But if you have WebDAV enabled on a public server, audit what methods you’re actually allowing.
CVE-2026-27651 ↗ affects nginx’s mail proxy module when CRAM-MD5 or APOP authentication is used with retry enabled. A segmentation fault in the worker process means the request dies and the worker restarts. That’s availability impact, not data exposure. If you’re not running nginx as a mail proxy, this doesn’t touch you.
CVE-2026-27784 ↗ and CVE-2026-32647 ↗ both live in the MP4 module. The first affects 32-bit platforms specifically; the second affects all platforms. Both result in worker process crashes when processing a specially crafted MP4 file. If you’re not using ngx_http_mp4_module, nginx doesn’t compile or load it by default on most distributions anyway. Check with nginx -V 2>&1 | grep mp4 to confirm.
CVE-2026-28755 ↗ is the one that surprised me. In the stream module, an OCSP check could reject a client certificate and the TLS handshake would succeed anyway. The entire point of OCSP is to revoke certificates that should no longer be trusted. A bypass here means a revoked cert gets through silently. Most deployments don’t use stream with mutual TLS, so the practical impact is limited. But the failure mode is worth knowing: the check ran, it said no, and nginx said yes anyway.
CVE-2026-28753 ↗ is the DNS injection one. When nginx does reverse DNS lookups for auth_http or the XCLIENT command in SMTP proxy flows, it uses the PTR record response as input. An attacker who controls the DNS server answering those PTR queries can inject data into the headers sent to your backend. Exploiting this requires controlling upstream DNS, which raises the bar considerably. Still, it belongs to a class of bugs that keeps appearing across different software: DNS responses are attacker-controlled data, and treating them as trusted input is the root cause every time.
QUIC improvements#
This release also ships two non-CVE changes to QUIC handling worth noting.
nginx now limits the size and rate of QUIC stateless reset packets. Without this, a misbehaving or malicious peer could trigger an unbounded volume of stateless resets. The second fix addresses a bug where a QUIC packet received by the wrong worker process caused the connection to terminate instead of being handed off correctly.
Neither of these is a security vulnerability with a CVE, but both affect connection stability for any deployment using QUIC.
Updating#
apt upgrade nginx
nginx -v
systemctl status nginxbashThe package post-install script handles the service restart. No config changes, no downtime beyond the few seconds nginx takes to reload. Worker processes drain and restart cleanly.
After the upgrade, nginx -v should show nginx/1.28.3. If the status shows the service running with a timestamp matching your upgrade, you’re done.