Four CVEs Hitting nginx 1.24 — and How to Get Off It

1. Why this post exists

nginx 1.24 is the legacy-stable branch that most production fleets quietly settled on after it shipped in April 2023. It is the default in Debian 12 and Ubuntu 24.04 LTS, and a lot of self-compiled installs were never updated past the original 1.24.0 tarball. That part is fine — the part that isn't fine is that nginx 1.24 is no longer in the upstream security-backport window. F5 only ships CVE fixes against the currently maintained stable branch (1.26.x → 1.28.x) and mainline. If you are on 1.24 and you are not getting your fixes through a Linux distribution's security channel, you are exposed.

2. The structural fact worth pinning to your wall

Before the per-CVE walkthrough, the one number that frames every fix decision:

Every CVE listed below has its "Not vulnerable" cutoff at 1.26.x+ or 1.27.x+. None of them have an upstream patch for the 1.24.x line. That is not an oversight — that is nginx's branch policy. Stable branches stop receiving backports the moment they are superseded by the next stable branch.

The practical consequences by deployment shape:

The rest of this post assumes you cannot immediately move off 1.24. If you can, do that first — the rest is triage while you plan the move.

3. The four CVEs at a glance

Severity for all four sits at "medium" because the impact requires specific modules or upstream topologies — but the *blast radius* when those conditions hold is large. Two of them break trust boundaries the reverse proxy is supposed to enforce.

4. CVE-2025-23419 — SSL session reuse vulnerability

Severity: Medium · Vulnerable range: 1.11.4 – 1.27.3 (includes all 1.24.x) · Fixed in: 1.27.4+, 1.26.3+

Sources:

• nginx advisory index: https://nginx.org/en/security_advisories.html
• NVD record: https://www.cve.org/CVERecord?id=CVE-2025-23419

What it is

A flaw in nginx's SSL/TLS session-cache logic lets a reused session be leveraged to bypass client-certificate verification under specific configurations. The most common trigger is a server block that combines ssl_session_cache shared:SSL:10m; with ssl_verify_client on; — the exact combination you write when you want mTLS at scale without paying the per-handshake cost.

Who is exposed

Every nginx deployment doing mutual TLS: API gateways that use client certs, admin UIs that put a cert-based login in front of an internal tool, service-mesh-adjacent zero-trust setups, anything where the security story is "we know who you are because of your cert." This is the CVE that should worry reverse-proxy operators on this list, because:

• The attack surface is the *normal* client-cert flow, not a misconfigured edge case.
• A successful bypass lets an attacker with a *valid but unrelated* TLS session authenticate as a different client.
• It does not require a special network position — any legitimate client who can resume a session can attempt it.

Why "medium" is misleading

CVE scoring tends to underweight "this breaks the whole point of your auth model." If your security story involves mTLS — and a lot of modern zero-trust and service-mesh-adjacent architectures do — this is not a medium. This is the one to fix first.

Fix path

• Upgrade to 1.26.3+ or 1.27.4+ (or to the current stable, 1.28.x — see §10).
• Distro users: confirm your vendor's 1.24 build includes the backport. If not, push for the package or move to the next stable major your distro provides.
• Cannot upgrade today: disable shared SSL session caching on mTLS endpoints. Set ssl_session_cache off; (or a non-shared cache) inside server { } blocks that do ssl_verify_client on;. Sessions can still be reused; the bypass primitive changes.

5. CVE-2026-1642 — SSL upstream injection

Severity: Medium · Vulnerable range: 1.3.0 – 1.29.4 (includes all 1.24.x) · Fixed in: 1.29.5+, 1.28.2+

Sources:

• nginx advisory index: https://nginx.org/en/security_advisories.html
• NVD record: https://www.cve.org/CVERecord?id=CVE-2026-1642

What it is

When nginx terminates SSL on the client side and opens an upstream SSL connection (i.e., proxy_pass https://backend with the proxy_ssl_* directives), an attacker can inject data into the upstream connection through SSL session handling. The injection happens *inside* the trusted upstream TLS tunnel — meaning anything that trusts nginx-as-proxy is now trusting attacker-controlled bytes.

Who is exposed

This is the most common reverse-proxy / load-balancer pattern in production:

server {
    listen 443 ssl;
    ssl_certificate     /etc/nginx/certs/example.com.pem;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    location / {
        proxy_pass https://internal-backend:8443;
        proxy_ssl_name       internal-backend;
        proxy_ssl_server_name on;
    }
}

If your nginx.conf has any proxy_pass https://... block, you are exposed until you upgrade.

Why this is the second "medium" on the list

The blast radius is the trust boundary your reverse proxy is supposed to enforce. An attacker who can inject bytes into the upstream connection can:

• Spoof internal-only API calls that "should" be authenticated by network position.
• Bypass header-based auth (X-Internal-Token) by injecting the header *after* nginx strips it.
• Trigger SSRF-like behavior on backends that trust their upstream.

The CVE is "medium" in the scoring sense. In the operational sense, for a reverse-proxy deployment, treat it as critical.

Fix path

• Source users: upgrade to 1.28.2+ or 1.29.5+. There is no 1.24.x fix path upstream. If you compile from source, this is the CVE that forces the move.
• Distro users: check your distribution's security tracker. Some vendors will backport; others will push you to a newer major.
• Cannot upgrade today: route upstream-SSL traffic through a separate proxy that *can* be upgraded, or terminate the upstream TLS at the backend itself and use plain HTTP between nginx and the backend (only safe on a trusted network). Also ensure proxy_ssl_verify on; and proxy_ssl_name are set strictly — this is the documented mitigation for reducing injection primitives even on a vulnerable version.

6. CVE-2026-27654 — Buffer overflow in ngx_http_dav_module

Severity: Medium · Vulnerable range: 0.5.13 – 1.29.6 (includes all 1.24.x) · Fixed in: 1.29.7+, 1.28.3+

Sources:

• nginx advisory index: https://nginx.org/en/security_advisories.html
• NVD record: https://www.cve.org/CVERecord?id=CVE-2026-27654

What it is

A buffer overflow in the WebDAV module that can be triggered by crafted client requests against a vhost that has WebDAV methods enabled. The overflow is in nginx's process address space, so a successful exploit runs as the nginx worker UID — typically a low-privilege account, but with full read access to anything nginx can read.

Who is exposed

Only nginx configurations that explicitly enable the WebDAV module — typically file-sync, upload portals, or collaboration-tool frontends:

location /dav/ {
    root                   /var/lib/dav;
    dav_methods            PUT DELETE MKCOL COPY MOVE;
    dav_access             user:rw group:rw;
    create_full_put_path    on;
}

If you don't have dav_methods (or the older dav;) in your config, you are not exposed. The WebDAV module is opt-in.

Why it earns its slot in the top 4

The WebDAV module is one of the four "watch for these on 1.24" modules the brief explicitly flags (dav, charset, mp4, rewrite). Most nginx operators don't think about it because WebDAV is opt-in and a relatively rare production pattern — but if you happen to be the operator that turned it on for a file-sync or upload feature, this is the CVE that will bite you, and it almost never appears in "what CVEs affect nginx?" summaries because the general lists assume plain HTTP/TLS deployments.

Fix path

• Source users: upgrade to 1.28.3+ or 1.29.7+.
• Distro users: confirm your vendor's 1.24 build includes the backport.
• Cannot upgrade today: remove dav_methods (and the standalone dav; directive) from any public-facing vhost. If the upload/sync feature is required, front it with a reverse proxy that *can* be upgraded and have the proxy validate and strip WebDAV-specific headers before they reach the unpatched backend.

7. CVE-2026-28753 — Command injection in auth_http + XCLIENT

Severity: Medium · Vulnerable range: 0.6.27 – 1.29.6 (includes all 1.24.x) · Fixed in: 1.29.7+, 1.28.3+

Sources:

• nginx advisory index: https://nginx.org/en/security_advisories.html
• NVD record: https://www.cve.org/CVERecord?id=CVE-2026-28753

What it is

A command injection vulnerability in the mail proxy's auth_http handler when XCLIENT is enabled. Crafted XCLIENT attributes forwarded through the auth_http call can be interpreted as additional commands by the auth backend, allowing an attacker to execute actions outside the intended authentication handshake.

Who is exposed

Only nginx deployments running as a mail proxy with auth_http and xclient enabled:

mail {
    auth_http            http://auth.internal:8080/auth;
    xclient              on;
    server {
        listen           110;
        protocol         pop3;
        pop3_auth        plain apop cram-md5;
    }
}

If your nginx only serves HTTP and HTTPS, this CVE does not affect you. Like CVE-2026-27654, it earns its slot because the brief explicitly flags it as part of the 1.24 risk surface — and because most "what CVEs affect my nginx?" lists won't include a mail-subsystem CVE at all.

Why it earns its slot in the top 4

Two reasons. First, it has the same profile as CVE-2026-27654: medium CVSS, narrow configuration footprint, high blast radius when that footprint matches your deployment. Second, the XCLIENT injection primitive reaches *outside* nginx — into whatever backend auth_http calls. If your auth backend is a shell-out or a thin wrapper around one, the injection primitive is a remote command-execution primitive.

Fix path

• Source users: upgrade to 1.28.3+ or 1.29.7+.
• Distro users: confirm your vendor's 1.24 build includes the backport.
• Cannot upgrade today: do not expose the mail auth_http endpoint to untrusted networks. Validate XCLIENT inputs at the MTA layer. If you control the auth backend, sanitize the parameters nginx forwards to it before they reach any shell-out.