nginx TLS session ticket vulnerability: a rotation bug

The nginx TLS session ticket vulnerability fixed this month has three different descriptions depending on where you read it, and only one of them tells you whether you are affected. nginx's advisory calls it "Session forgery when using TLS session tickets" and rates it medium. Coverage describes it as a forged session that skips client-certificate checks, with F5 scoring it 8.3. nginx's changelog is the one that names the precondition: key rotation left one key uninitialized.

That changes the audit from "do we use TLS" to something you can actually grep for.

What the nginx TLS session ticket vulnerability actually is

The 1.30.6 changelog entry reads in full: "Security: when using TLS session ticket key rotation, one of the keys was left uninitialized, which might allow to forge a session (CVE-2026-97629). Thanks to PhiNode Labs."

Unpack that. Session tickets let a client resume a TLS session without a full handshake: the server encrypts the session state under a ticket key and hands it to the client, who presents it back later. The security of the whole mechanism rests on that key being secret and unpredictable. An uninitialized key is neither — and if an attacker can guess or derive it, they can mint a ticket for a session that was never negotiated. The server then resumes a session it believes it established.

The advisories page gives the range: vulnerable 1.23.2 through 1.31.6, not vulnerable 1.31.7+ and 1.30.6+. That is a narrower window than most of the October set, but it still covers three years of releases.

Why "session forgery" and "client-cert bypass" are both right

nginx's own wording stops at forging a session. Reporting on the release goes further, describing a forged TLS session that skips client-certificate verification, attributing a score of 8.3 to F5 and describing the behaviour as non-deterministic.

We could not read F5's advisory directly — the article pages render as an empty application shell without a browser session — so take the 8.3 and the non-determinism as reported rather than quoted. But the escalation is not a stretch, and it is worth spelling out because it decides how seriously to treat a "medium".

In mutual TLS, the client certificate is verified during the full handshake. A resumed session inherits the verified identity from the session state rather than re-presenting the certificate — that is the point of resumption. So if you can forge the session state, you inherit an authenticated identity you never proved. The bug is session forgery; the consequence, where mTLS is an access control, is an authentication bypass.

Which means the severity depends entirely on what your client certificates are for. If mTLS is belt-and-braces on top of application auth, medium is fair. If mTLS is the control on an admin path or a partner API, treat it as the highest-priority item in the release.

The workarounds point in a confusing direction

Here the sources need reconciling. nginx publishes no workaround for any of the five October CVEs. The reported F5 guidance is to remove the shared cache directive, or to load keys with ssl_session_ticket_key, and notes that ssl_session_tickets off is not affected.

Read that against the changelog and it looks backwards at first: the bug is in key rotation, and the advice is to supply keys explicitly — which is how rotation is configured. The reading that reconciles them: when you do not provide keys, nginx generates and rotates them internally, and that automatic path is where a key was left uninitialized. Supplying keys with ssl_session_ticket_key takes you off it. We are inferring that from the two statements rather than reading it anywhere, so verify before you rely on it.

The unambiguous option is the third one. ssl_session_tickets off; removes the mechanism entirely and is reported as unaffected. It costs you resumption performance — full handshakes for returning clients — which on a busy TLS terminator is a real cost, but it is a config change you can make in minutes and reason about completely.

What to check

Dump the effective config and look at three directives:

nginx -T 2>/dev/null | grep -nE 'ssl_session_tickets|ssl_session_ticket_key|ssl_session_cache|ssl_verify_client'

Then read it as a decision rather than a count. If ssl_session_tickets off is already set, this CVE is not yours. If tickets are on and no ssl_session_ticket_key is configured, you are on the automatic rotation path the changelog describes. And if ssl_verify_client appears anywhere alongside tickets, that is the block to patch first, because that is where forgery becomes a bypass.

One operational note that applies after you upgrade: existing sessions are not retroactively invalidated. A client holding a ticket minted by the vulnerable build can keep resuming until it expires, so rotating your ticket keys after the upgrade is part of the fix, not a precaution. The same principle came up in Node.js's TLS fixes in the same fortnight: patching the code does not reach back into sessions already established.

What we would do

Upgrade to 1.30.6 on stable or 1.31.8 on mainline — not the 1.31.7 the advisory names, which the download page has already superseded. Then rotate ticket keys and restart rather than drain, so nothing resumes on the old state.

If mTLS is load-bearing for you, do the config check before the upgrade rather than after, because the answer determines whether this is a routine patch or an incident-adjacent one. And if you are evidencing TLS controls to a customer or regulator — as you must under frameworks where a vendor has to evidence its controls — note that "we terminate TLS with mutual authentication" is a weaker claim this month than it was last month, and that the honest version names the version you run.

The rest of the release, including the severity disagreement between nginx and F5 across all five CVEs, is in our walkthrough of nginx 1.30.6.