Tink-Go EUVD-2026-97823

Exploitation requires that the target application load a keyset through the specific APIs keyset.NewHandleWithNoSecrets() or keyset.ReadWithNoSecrets() AND that the keyset source be attacker-influenced (e.g., an externally-provided public keyset). The affected version is tink-go through 2.8.0. The key limiting factor is that applications using the standard secret-bearing keyset handle APIs, or that independently validate keysets, are not exposed; impact is bounded to integrity of the resulting handle (malformed keyset accepted, e.g., enabled public key lacking a valid primary, or a DESTROYED key with no KeyData) and the correctness of downstream consumers such as jwt.JWKSetFromPublicKeysetHandle(). No secret key material is exposed and there is no code-execution or availability impact.

This is a genuine but low-to-moderate severity integrity/validation flaw rather than a high-impact priority. The input CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated issue, but the only impact metric set is VI:L - low integrity impact, with confidentiality (VC:N) and availability (VA:N) explicitly unaffected - yielding a modest 6.9. The actual defect is a missing structural Validate() call that lets malformed public/no-secret keysets be accepted; it does not disclose secret key material or grant code execution. POC exists (the upstream tink-go issue), but there is NO CISA KEV listing and NO EPSS score provided, so there is no evidence of active or widespread exploitation. The AV:N rating is conditional: exploitation only matters if an application ingests attacker-supplied keysets through NewHandleWithNoSecrets()/ReadWithNoSecrets(), which is a specific deployment pattern rather than a universal exposure - verify whether your application accepts externally-sourced keysets. Net: real defensive-depth bug worth patching on a normal cycle, not an emergency.

An application loads an externally-supplied public/no-secret keyset via keyset.NewHandleWithNoSecrets() or ReadWithNoSecrets() and treats successful handle construction as proof of keyset integrity. An attacker submits a malformed keyset - e.g., an enabled public key with no valid primary, or a DESTROYED key lacking KeyData - which is accepted without validation and then processed by downstream code such as jwt.JWKSetFromPublicKeysetHandle(), producing an inconsistent or misleading JWK set. Publicly available POC/discussion exists in the upstream tink-go issue tracker.