Of the five flaws fixed in NGINX 1.30.6 and 1.31.7, CVE-2026-97629 is the one that breaks an authentication assumption rather than a memory boundary. Under specific conditions an attacker can present a TLS session ticket that NGINX will accept and decrypt using key material it never initialized, producing what F5 calls a forged session. The practical consequence is that certificate-based client authentication can be bypassed without any private key.

Background: how ticket keys are supposed to work

Session tickets let a client resume a TLS session without a full handshake. The server encrypts the session state with a ticket key and hands the result to the client; on resumption the client returns the ticket and the server decrypts it with the same key.

Historically operators managed those keys themselves. Since 1.23.2, released in October 2022, a shared session cache changes that: when ssl_session_cache shared:SSL:10m is configured and no key file is loaded through ssl_session_ticket_key, NGINX generates and rotates ticket keys on its own. That directive is not exotic. It is the form NGINX's own documentation uses in its example configuration, which means many deployments inherited it without thinking about key lifecycle.

The bug

Automatic rotation keeps three key slots per worker process, so that a recently retired key can still decrypt tickets issued moments earlier. The rotation routine copied only two of the three slots forward. The third slot therefore retained whatever bytes happened to be in that memory beforehand.

A ticket that names the stale slot could then be verified and decrypted with that uninitialized material. Because the attacker does not know what those bytes are, the forgery is not deterministic: F5 describes it as working in a non-deterministic manner that is beyond the attacker's control. That qualifier matters for risk assessment, and it does not remove the security consequence. A ticket that decrypts successfully carries whatever session state the attacker packed into it, including a claim that client-certificate verification already happened.

Exploitation conditions

Three conditions must hold together. The server must run an affected version, which the advisory range places at 1.23.2 through 1.31.6. It must use a shared ssl_session_cache directive. And it must not load explicit keys through ssl_session_ticket_key, so that automatic rotation is active.

Servers with ssl_session_tickets off are outside the affected set, because no ticket processing occurs. Servers that load a key file are also outside it, because no automatic rotation occurs.

Where certificate authentication protects an administrative interface, a resumption bypass is more than a curiosity. It turns "you need a client certificate" into an assumption that a particular memory layout will not cooperate with an attacker.

Impact and blast radius

The direct impact is authentication bypass on TLS listeners that enforce client certificates and rely on the shared cache. The secondary impact is that the bypass is silent: a successful resumption produces a normal-looking session, so nothing in the access log distinguishes it from a legitimate resume unless ticket handling is logged in detail.

F5 scores the flaw 8.3 on CVSS v4.0, below the 9.2 assigned to the three memory bugs in the same release, but above the HTTP/3 issue at 6.9. NGINX's own advisories rate it medium. Neither party reported exploitation.

Remediation

Upgrade to 1.30.6 or 1.31.7. That is the complete fix.

Two workarounds exist for teams that cannot move immediately. Removing the shared session cache directive eliminates the automatic rotation path. Alternatively, load keys from a file with ssl_session_ticket_key, which takes key management back under operator control. The second option is the better long-term posture for any listener that enforces client certificates, because explicit keys make rotation a deliberate act rather than an implementation detail.

Operators should also review whether the shared cache was ever needed. It exists to make resumption work across worker processes; deployments that terminate TLS in a single worker, or that do not care about cross-worker resumption, gain little from it.

Verification steps

Run nginx -T and look for ssl_session_cache shared in any server or http block. For each occurrence, check whether ssl_session_ticket_key appears in the same context, and check whether ssl_session_tickets is disabled. A listener that enforces ssl_verify_client while relying on automatic ticket keys is the combination to fix first.

A forged session does not prove an attacker knows a client key, and a scanner cannot confirm the flaw from outside: the condition is server-side configuration, not a banner. Treat the configuration review as the authoritative check.

Sources

  • NGINX security advisories: https://nginx.org/en/security_advisories.html

  • F5 advisory K000162606: https://my.f5.com/manage/s/article/K000162606

  • Ticket rotation fix commit: https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

  • ssl_session_cache documentation: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache

  • ssl_session_ticket_key documentation: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key