FR
live

nginx patches a heap overflow in the HTTP/3 handshake of its edge servers

On September 15, 2026, nginx shipped 1.31.6 and 1.30.5 to close CVE-2026-90439, a heap buffer overflow in its HTTP/3 module that hits builds linked against OpenSSL 3.5.0 or earlier. Upgrade both nginx and OpenSSL, then disable HTTP/3 on edges that do not need it.

A postal sorting conveyor carrying small dark parcels, a single parcel split open at one corner with an amber gleam.

September 15, 2026. nginx ships 1.31.6 (mainline) and 1.30.5 (stable), both carrying a security fix. September 2. The 1.31.5 release had opened a new feature chapter: a control API, predicate locations and a native JSON module. 3.5.0. The OpenSSL version above which the trigger disappears. Why it matters: the bug lives in HTTP/3, the newest and least-battle-tested corner of an edge server — the one many teams expose to the internet without realising it is even switched on.

HTTP/3 became a default surface, not a considered choice

nginx is the most widely deployed reverse proxy and web server on the internet, and HTTP/3 arrived there later than in several competing implementations. That has two consequences. On one side, the installed base is enormous, so any patch touches a vast number of instances. On the other, HTTP/3 is built on QUIC, a transport that runs over UDP rather than TCP — a full model change, not simply “faster HTTP”.

The operational point is what matters. Plenty of operators switched HTTP/3 on by following a deployment recipe — the listen 443 quic reuseport; directive and the Alt-Svc header — and never revisited it. The result is an extra network surface open on boxes that previously spoke only TCP. That is exactly the surface CVE-2026-90439 targets.

What the flaw actually does

The vulnerability sits in ngx_http_v3_module, the module that implements HTTP/3. According to the advisory, a limited heap buffer overflow can occur during the TLS handshake of a QUIC connection when two conditions are met: the server is built against OpenSSL 3.5.0 or earlier, and certain specific configurations are in place.

Three properties make this one unusual. First, the trigger is non-deterministic — the vendor itself writes that it happens “in a manner beyond the attacker’s control”. Second, the impact is twofold: a worker process restart (denial of service) and limited data corruption. Third, the CVSS 6.5 score files it as “medium”, but that number hides the essential point: the corruption happens inside the same worker that handles every other request, and the availability impact hits the whole edge, not a single connection.

The scope covers nginx Plus and nginx Open Source. The fix landed in both branches at once — 1.31.6 for mainline and 1.30.5 for stable — alongside a separate hardening change: the QUIC transport parameters extension received in an SSL connection is now always ignored.

Why OpenSSL 3.5.0 is the real risk marker

The OpenSSL link is not a footnote. The flaw only exists when the nginx binary was linked against an OpenSSL version at or below 3.5.0. That means upgrading nginx alone is not always enough: a package rebuilt against an obsolete OpenSSL can remain vulnerable despite a recent nginx version.

One command settles it, and it is more reliable than reading the version number alone:

bash
# List the nginx version and the OpenSSL build it was linked against
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'nginx/|OpenSSL'

As long as the built with OpenSSL line reads 3.5.0 or lower, the application patch is incomplete — the OpenSSL library used at link time must also be updated.

Disable HTTP/3, or keep it on a leash

For an edge server that does not need HTTP/3, the cleanest move is simply removing the QUIC listen directive:

nginx
server {
    listen 443 ssl;
    # listen 443 quic reuseport;   # <- comment/remove to disable HTTP/3
    server_name example.com;
}

For deployments that want to keep HTTP/3, the minimum posture is a coordinated upgrade of nginx and OpenSSL, followed by monitoring of the worker restart rate. A worker crash-looping on an exposed QUIC edge is precisely the symptom CVE-2026-90439 produces.

The episode reflects a broader trend. HTTP/3 is the first major rework of web transport in years, and its adoption was driven by latency and CDN economics more than by security reasoning. Bugs in this layer are mechanically younger, less documented and less covered by legacy detection tooling — IDS and firewalls that still parse TCP do not always see QUIC traffic the same way. The September 15 patch is a reminder that this new surface has not yet entered most teams’ hardening routine. The retirement of ingress-nginx in favour of the Gateway API in Kubernetes, which we covered here, is also shifting part of that responsibility onto other implementations that will need the same level of scrutiny.

Verdict

CVE-2026-90439 is not a front-page CVSS 9.8, but it is a useful signal about a surface few teams genuinely watch. If you expose nginx to the internet with HTTP/3 enabled, move to 1.30.5+ or 1.31.6+ and check the linked OpenSSL version — both, not one or the other. If you do not use HTTP/3, remove the listen … quic directive: you eliminate the risk without waiting for any patch. If you manage a fleet of proxies, add the “nginx version + linked OpenSSL version” pair to your compliance inventory, because it is the combination — not either number in isolation — that determines exposure.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

← Back to the feed

Type at least two characters.

navigate open esc dismiss