Eclipse KeyPont gose CVE-2026-89313

Requires three concrete conditions drawn from the advisory: (1) the TrustStore must be a JwksTrustStore backed by a JWKS document that holds more than one key (the rotation scenario), (2) the attacker-supplied compact JWT must set iss to a value already on the operator's issuer allowlist so foundIssuer is true, and (3) the JWT's kid header must name a key that is absent from that JWKS, so the lookup misses and the naked return ships the last-parsed key with err=nil. LIMITING FACTORS: this is not an authentication bypass - JwtVerifierImpl.Verify still enforces algorithm match and signature verification against the returned key, so a forged token signed by an unrelated key is still rejected; the practical impact is limited to broken kid-to-key binding affecting key rotation and any downstream authorization/routing/audit logic that trusts kid, or to direct external callers of the exported Get/TrustStore interface. Single-key JWKS deployments and consumers that re-check the returned key's Kid() against the requested kid are not exploitable.

This is a logic/key-selection flaw in the gose JOSE library (CWE-706), not a high-urgency emergency. The supplied CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N) correctly captures a network-reachable issue with high attack complexity and only Low integrity impact and no confidentiality or availability impact. There is a scoring conflict that must be noted: the input header states 6.3, but the Eclipse GHSA advisory and the same 4.0 vector actually compute to roughly 3.7 (Low), and the maintainer explicitly rates it Low - treat 6.3 as likely mis-entered and the Low rating as authoritative. The vuln.today decision label is 'this_month' (not act_now/emergency). It is NOT in CISA KEV, so there is no confirmed active exploitation, and no EPSS probability was provided. The advisory stresses this is explicitly NOT an authentication bypass: JwtVerifierImpl.Verify still checks algorithm and verifies the signature against whatever key it receives, so a token signed by an unrelated key is still rejected. The real-world residual risk is confined to key-rotation windows and to downstream logic that trusts the kid-to-key binding; combined with AC:H (needs a multi-key JWKS plus a token naming an absent kid) this is a genuine correctness/defense-in-depth fix to schedule, not a drop-everything patch.

During legitimate key rotation when the JWKS holds several keys, an attacker submits a compact JWT whose iss matches an operator-allowlisted issuer and whose kid is absent from the current JWKS; JwksTrustStore.Get silently returns the last key in the document with err=nil, so a token that names a retired or not-yet-active key can still be validated against whichever key happens to be last. The Eclipse advisory describes an executed reproducer (an httptest JWKS server with two EC keys showing the wrong 'last' key returned for a non-existent kid), but no standalone weaponized exploit code is published. Because AC is High, exploitation depends on the specific multi-key/absent-kid condition rather than any default configuration.