Nginx 1.30.5 and 1.31.6: the HTTP/3 buffer overflow (CVE-2026-90439) and two commands to tell if you're exposed

HTTP/3 again

On 15 September nginx released 1.30.5 (stable) and 1.31.6 (mainline). Both have a single urgent reason to exist: CVE-2026-90439, a buffer overflow in ngx_http_v3_module, the module behind HTTP/3 support.

The good news is that this time the bug is not universal. The bad news is that if you run HTTP/3 —and more and more people switch it on because browsers reward it— you should check today, not "at some point".

In one sentence

With HTTP/3 enabled and nginx linked against OpenSSL 3.5.0 or earlier, a remote, unauthenticated attacker can trigger a limited memory overflow in a worker during the TLS handshake, which ends up restarting the worker and may corrupt some data. Medium severity: CVSS 6.5 on v3.1 and 6.9 on v4.0, according to F5 itself.

What we know about the bug

• Where it lives: in TLS handshake processing for HTTP/3 (QUIC) connections.
• What it causes: worker restarts and, at most, limited data corruption. F5 doesn't attribute any information leak or code execution to it, and notes that the effect is non-deterministic and not under the attacker's control.
• What it doesn't touch: it's data plane only. There's no control plane exposure.
• Who found it: Banny Liao, per the nginx changelog.
• Is it being exploited? As of today there's no evidence of exploitation and no public proof of concept. But CISA's assessment flags it as automatable: nothing fancy is needed to spray it at exposed servers.

Besides the fix, both releases change one behaviour: the QUIC transport parameters extension received over a regular SSL connection is now always ignored. Mainline 1.31.6 also ships a handful of bug fixes unrelated to security.

Who's affected

Both conditions have to be true:

1. Vulnerable version: 1.29.2 through 1.31.5. On the stable branch, that covers 1.30.x releases before 1.30.5. NGINX Plus is affected too; the fix is in 37.1.1.2 and 37.0.6.2.
2. HTTP/3 enabled (any listen directive with quic) and OpenSSL 3.5.0 or earlier.

If your nginx is older than 1.29.2, the vulnerable code isn't there. That's typical of packages from stable distributions, which tend to lag several versions behind; still, check rather than assume. And if you don't use HTTP/3, this bug can't reach you even if your version falls in the range.

What to do today

1. Check the version and OpenSSL

nginx -V 2>&1 | head -3

The first line shows the nginx version, and another one shows the OpenSSL it was built with ("built with OpenSSL…"). Check the system one as well:

openssl version

2. Check whether HTTP/3 is on

nginx -T 2>/dev/null | grep -E "listen.*quic|http3"

If nothing comes back, HTTP/3 isn't enabled and you can relax about this CVE (and update anyway in your next window).

3. If you're affected: update and reload with no downtime

• Stable branch: aim for 1.30.5 or later.
• Mainline branch: aim for 1.31.6 or later.

# Debian / Ubuntu (official nginx.org repository)
sudo apt update && sudo apt install --only-upgrade nginx
sudo nginx -t && sudo systemctl reload nginx

# RHEL / AlmaLinux / Rocky
sudo dnf update nginx
sudo nginx -t && sudo systemctl reload nginx

Then run nginx -v again. If you haven't checked it, it isn't done.

4. If you can't update today

F5 suggests two temporary workarounds:

• Disable HTTP/3 by removing quic from your listen directives. Browsers will fall back to HTTP/2, and users won't notice anything beyond a touch of extra latency.
• Or enable it on every server block that shares the configuration, adding quic to all of them. F5 doesn't explain why; if you go this way, test it outside production first.

The first one is simpler and safer. The second is best left to people who already know why they're doing it.

How we approach it

This is the kind of CVE where an inventory pays off: knowing in advance which servers run HTTP/3 and which OpenSSL each nginx was built against. With that, "am I affected?" takes minutes, not an afternoon of SSH-ing into one server after another.

And one thing worth keeping in mind: HTTP/3 code is far younger than HTTP/1.1 or HTTP/2 code. That's no reason to avoid it —we've already covered when it's worth turning on— but it is a reason to treat the quic in your listen as something you enable knowing it needs watching.

If you don't know which nginx version your server runs, or whether HTTP/3 is on, let's talk.

References

• nginx security advisories — nginx.org
• nginx CHANGES (1.31.6) — nginx.org
• nginx CHANGES-1.30 (1.30.5) — nginx.org
• NGINX vulnerability CVE-2026-90439 — F5 (K000162604)
• CVE-2026-90439 — NVD