Eclipse KeyPont gose CVE-2026-89317

Requires a trusted issuer to actually emit JWS tokens carrying a non-empty crit header naming a critical extension (e.g. RFC 7797 b64:false detached payload, RFC 7800 cnf proof-of-possession, or an ecosystem-specific must-revoke-check); if issuers never set crit, the flaw has no effect. The adversary must be able to legitimately obtain such a constrained token in one context and present it to a separate service that uses gose as its JWT/JWS verifier (cross-context replay). Exploitation is explicitly NOT available to an unauthenticated attacker lacking the signing key, because crit resides in the signed protected header and cannot be injected or altered without invalidating the signature. Limiting factors: the signature still verifies and claims remain authentic (integrity impact Low only); the deployed gose version must predate eclipse-keypont/gose v1.0.0-rc4; and the issuing ecosystem must rely on crit for a security property.

Signals diverge in a way that must be read carefully. The CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N, VI:L only, 6.3 Medium) implies a remote, unauthenticated attacker, but the Eclipse/GHSA advisory explicitly contradicts the PR:N reading: the crit member lives inside the signed protected header, so an unauthenticated party cannot inject or alter it without the issuer's signing key. The PR:N is therefore an artifact of the attacker presenting an already-valid token rather than true unauthenticated injection - verify this nuance before treating it as a drive-by remote flaw. No EPSS score and no KEV status were supplied, so there is no probabilistic or confirmed-exploitation signal; exploitation status here is 'no public exploit identified at time of analysis' in the KEV/weaponized sense, though a public PoC reference exists in the advisory (a reproducer with executed output) that is not verified as a distributable working exploit. The vuln.today Decision label is 'this_month', not act_now or emergency, consistent with the limited scope: integrity impact is Low (signature and claims remain authentic - only an issuer-mandated constraint is silently dropped), confidentiality and availability are unaffected, and the realistic attack is cross-context replay requiring specific preconditions. Net: this is a genuine spec-compliance/validation defect worth remediating on a normal patch cycle, not a high-urgency emergency; the headline-friendly PR:N/AV:N should not be mistaken for widespread unauthenticated exploitability.

A trusted issuer signs a JWS whose protected header carries a non-empty crit naming a mandatory extension - e.g. RFC 7800 cnf requiring proof-of-possession or an ecosystem must-revoke-check. An adversary who can legitimately obtain that token in one context presents it to a service that uses gose as its verifier; gose checks the signature, exp, nbf, aud, kid and alg, never reads Crit, and returns success, silently dropping the constraint the issuer marked mandatory. The advisory includes an RS256-signed reproducer showing such a token being ACCEPTED, but it is not verified as weaponized exploit code.