Tink‑go up through version 2.8.0 contains an input‑validation flaw where keyset.NewHandleWithNoSecrets() and ReadWithNoSecrets() skip the structural Validate() step that normally enforces Tink’s keyset invariants. This omission allows an attacker to supply a malformed keyset— for example, an enabled public key that is not the primary key or a DESTROYED key lacking KeyData—yet still create a keyset.Handle. Functions such as jwt.JWKSetFromPublicKeysetHandle() use that handle to generate a JWK set, which leads applications to believe they are operating on a valid keyset when in fact the integrity of the key material is compromised.

The affected vendor and product are tink‑crypto’s Tink‑go library for Go. All releases up through version 2.8.0 are impacted; newer releases are presumed to have corrected the validation bypass.

The CVSS score of 6.9 indicates medium severity. No EPSS score is provided and the vulnerability is not listed in CISA KEV, so no widespread public exploits are currently known. The likely attack vector involves an application that accepts keysets from untrusted sources— such as configuration files, user uploads, or external services— and passes them to the vulnerable functions. Because structural validation is omitted, malformed keysets can be treated as valid, potentially leading to incorrect cryptographic operations or misidentified public keys, which could degrade confidentiality, integrity, or availability of the protected data.