CVE-2026-109425 in tink-go
Summary
by MITRE • 10/12/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Tink-go versions through 2.8.0 represents a critical failure in input validation logic within the cryptographic library's key management subsystem. Specifically, the functions keyset.NewHandleWithNoSecrets() and ReadWithNoSecrets() were found to bypass the mandatory structural Validate() step that is typically executed during standard keyset construction. This deviation from expected security protocols allows malformed public or no-secret keysets, which violate Tink’s internal invariants regarding key structure and state, to be accepted into memory as valid handles. By skipping this validation phase, the library fails to enforce consistency checks on critical attributes such as primary key presence, enabled status of keys, and data integrity for destroyed keys. This design flaw creates a pathway where attackers can inject maliciously crafted inputs that appear structurally sound at the handle level but contain logical inconsistencies that compromise downstream cryptographic operations.
The operational impact of this vulnerability is significant because it undermines the assumption that successful construction of a keyset.Handle guarantees the integrity and correctness of the underlying keys. When an attacker supplies a malformed keyset, such as one containing an enabled public key without a corresponding valid primary key or a DESTROYED key lacking essential KeyData fields, the system proceeds to process these invalid structures. This leads to inconsistent downstream validation where subsequent functions like jwt.JWKSetFromPublicKeysetHandle() operate on compromised handles. The result is the generation of JSON Web Sets that may contain incomplete, incorrect, or misleading cryptographic material. Applications relying on Tink-go for secure key exchange and token signing are thus exposed to risks including authentication bypasses, integrity violations, and potential denial of service conditions if they assume handle validity implies full structural correctness without performing additional independent checks.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to adequately verify inputs before processing them in critical security functions. It also relates to CWE-697 Incorrect Comparison during validation of keyset states and attributes. In terms of attack vectors, this falls under ATT&CK technique T1553 Subvert Trust Controls, specifically involving code signing or certificate manipulation if the malformed keys are used to forge tokens or signatures that appear valid to downstream consumers who do not perform deep structural verification. The exploitation requires an attacker to have write access to keysets passed into these specific functions, which could occur in scenarios where user-controlled data influences cryptographic configuration or when integrating with untrusted third-party services providing public keys.
Mitigation strategies must focus on enforcing strict validation at the earliest possible stage of input processing. Developers should avoid using NewHandleWithNoSecrets() and ReadWithNoSecrets() unless absolutely necessary for specific low-level operations where performance is critical and trust in input source is absolute, and even then, manual verification steps should be implemented to replicate the missing structural checks. Upgrading to a patched version of Tink-go that restores the Validate() call within these functions is the primary remediation path. Additionally, applications consuming keysets from external sources or user inputs should implement independent validation logic using standard cryptographic libraries before passing handles to high-level abstractions like JWT processors. This defense-in-depth approach ensures that even if a library function fails to catch an anomaly, the application layer can detect and reject malformed structures before they lead to security failures such as forged tokens or compromised key integrity.