CVE-2026-109425: Tink-go 2.8.0 Keyset Validation Bypass via NewHandleWithNoSecrets
Tink-go (tink-crypto/tink-go) through 2.8.0 contains an input-validation vulnerability where keyset.NewHandleWithNoSecrets() and ReadWithNoSecrets() skip the structural Validate() step before constructing a keyset.Handle, allowing malformed public or no-secret keysets that violate Tink's keyset invariants to be accepted. Attackers can supply a malformed keyset, such as one with an enabled public key lacking a valid primary key or a DESTROYED key with no KeyData, causing inconsistent downstream validation where functions like jwt.JWKSetFromPublicKeysetHandle() process the invalid handle and produce a JWK set, potentially misleading applications that rely on successful handle construction as proof of keyset integrity.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using tink-go through 2.8.0 are exposed if they construct handles from public or no-secret keysets with keyset.NewHandleWithNoSecrets() or ReadWithNoSecrets(), particularly when the keyset input can be attacker-controlled.
What does an attacker need to provide?
An attacker needs to supply a malformed public or no-secret keyset that violates Tink keyset invariants. Examples include an enabled public key without a valid primary key or a DESTROYED key with no KeyData.
How can an application identify potentially affected behavior?
Check whether malformed keysets are accepted by NewHandleWithNoSecrets() or ReadWithNoSecrets() and result in a keyset.Handle rather than being rejected. A downstream sign is that jwt.JWKSetFromPublicKeysetHandle() can process such an invalid handle and produce a JWK set.