JLSEC-2026-802 json
TLS 1.2 session resumption can renew one master secret indefinitely
published 3mo ago modified 3mo ago
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
Reseau 1.1.0 through 1.3.1 issue a fresh TLS 1.2 session ticket after a resumed handshake by copying the original master secret while resetting the ticket's creation and expiry times. A client that resumes at least once during every ticket lifetime can keep the same master secret valid indefinitely.
### Impact
Indefinite renewal weakens the intended bound on a resumption secret's lifetime and erodes forward secrecy. If that master secret, or the server's ticket-encryption key together with a usable ticket, is later compromised, an attacker may be able to decrypt a much larger window of captured resumed-session traffic than the configured ticket lifetime suggests.
The issue does not by itself disclose a ticket or secret; the attacker must first possess a valid ticket or obtain the relevant key material.
### Technical details
The resumed-server handshake copied the cached session's `master_secret` into a new ticket but set `created_at` to the current time and `use_by` to seven days later. Because no absolute age was carried forward, chained resumptions renewed the same secret without limit.
This ticket implementation was introduced with Reseau's native TLS stack in version 1.1.0. Releases 1.0.x used the previous OpenSSL TLS engine and are not affected.
### Patches
Upgrade to Reseau 1.3.2 or later. Resumed tickets now preserve the original secret's creation and expiry timestamps, and resumption is rejected once that absolute lifetime expires so that a full handshake establishes fresh key material.
### Workarounds
Set `session_tickets_disabled = true` in the TLS configuration, or configure the service to require TLS 1.3, until Reseau can be upgraded. Operators can also rotate ticket-encryption keys and force full handshakes more frequently, but that is less reliable than disabling the vulnerable TLS 1.2 resumption path.
Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.
Patch / fix
- julia Reseau 1.3.2
Is JLSEC-2026-802 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| julia | Reseau | >=1.1.0, <1.3.2 |
1.3.2 |
References
Sources
- OSV JLSEC-2026-802
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.