CVE-2026-97629: NGINX session ticket keys can allow forged TLS sessions

What it is

NGINX can encrypt TLS session tickets with keys it rotates automatically. When ssl_session_cache shared is configured and no ssl_session_ticket_key file is set, a flaw in that setup lets a remote, unauthenticated attacker forge client SSL sessions. The CVE record says the result is non-deterministic and outside the attacker’s control, but it could bypass client certificate verification.

If your NGINX uses client certificates (mutual TLS) to decide who can reach a backend, that is the check at risk. The impact is limited to the data plane, and the record says it could expose resources or sensitive information. F5 rates it CVSS 3.1 6.5 (medium, high attack complexity) and CVSS 4.0 8.3 (high). The weakness is CWE-908, use of an uninitialized resource.

The CVE record does not mention exploitation, and we found no public proof of concept. It was published on October 14, 2026.

Am I affected?

You are exposed only if both are true:

1. You run an affected version (see the table above). F5 did not evaluate versions past End of Technical Support.
2. Your configuration uses ssl_session_cache shared:<name>:<size> and does not load static keys with ssl_session_ticket_key.

Client certificate verification is the check this flaw can bypass, so servers that rely on it are the highest priority.

Check your configuration for those two directives in every server and http block that terminates TLS. Setting ssl_session_tickets off is not affected.

The record lists NGINX Plus R33 to R36 and NGINX Open Source 1.23.3 as affected with no fixed version. Move off them to a fixed release.

What to do

1. Upgrade. NGINX Open Source: 1.31.7 or 1.30.6. NGINX Plus: 37.1.0.1 or 37.0.5.1. If you run an older Plus release (R33 to R36) or Open Source 1.23.3, plan a move to one of those branches.
2. If you can’t upgrade tonight, use one of the vendor workarounds:
   • Remove the ssl_session_cache shared:name:size directive. Production impact: you lose shared session resumption across workers, so expect more full TLS handshakes and some extra CPU load.
   • Load static ticket keys with the ssl_session_ticket_key directive. Static keys must be generated, stored securely and rotated by you.
3. Reload NGINX after any configuration change.
4. If you rely on client certificates and ran an affected setup, review access logs for the period before the fix (see Detection). Treat unexpected access to client-certificate-protected resources as a possible bypass.

Detection

The sources give no specific log signatures for this issue, so detection is about spotting access that should have required a client certificate:

• Requests to client-certificate-protected locations that succeed without a certificate subject recorded in the access log (for example, an empty $ssl_client_s_dn).
• Resumed TLS sessions ($ssl_session_reused set to r) on those locations from clients or addresses you don’t recognise.
• Access to protected resources from sources outside your expected client networks.

These log variables are standard NGINX variables, not taken from the advisory. Use them as starting points and confirm against the F5 advisory.