Eclipse KeyPont gose EUVD-2026-108648

Exploitation requires a consuming application to pass an externally supplied (attacker-influenced) JWK document directly to the exported LoadPublicKey or LoadPrivateKey - for example a caller-built JWKS loader. The triggering input is a JWK declaring "kty":"EC" together with a non-EC "alg" (RS256, RS384, PS256, RSA-OAEP, or RSA-OAEP-256), which jose.UnmarshalJwk accepts because it selects the Go type from kty alone and the publicKeyAlgs gate is kty-blind. LIMITING FACTORS: the vulnerability is NOT reachable through gose's own JWKS-to-verification path (NewVerificationKey gates EC on alg ∈ {ES256,ES384,ES512}); it needs the non-default integration described above, which is why attack complexity is rated High. No authentication is required on the vulnerable path (CVSS PR:N), and impact is limited to availability (process panic). Documented workarounds: do not forward external JWKs directly to LoadPublicKey/LoadPrivateKey - route through NewVerificationKey, or validate that kty and alg agree (an EC key must carry ES256/ES384/ES512) before loading.

This is a medium-severity denial-of-service issue (vendor CVSS 4.0 base 6.3), and the signals consistently point to bounded, conditional risk rather than an urgent threat. The CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N) scores availability only (VA:L) with no confidentiality or integrity impact (VC:N/VI:N) - matching CWE-248 (uncaught panic). AC:H is the pivotal metric: the advisory is explicit that no in-tree gose code path routes network-fetched JWK bytes to the sink, because gose's own JWKS-to-verification wiring goes through NewVerificationKey, whose EC branch gates on alg ∈ {ES256,ES384,ES512} and is immune; exploitation requires a consuming application that forwards an externally supplied JWK directly to the exported LoadPublicKey (or LoadPrivateKey). No EPSS score and no KEV listing are provided in the input, and there is no 'confirmed active exploitation' signal. The vuln.today Decision label is 'this_month' (not act_now/emergency), consistent with a real-but-non-emergency defect. The GHSA advisory contains an executed reproducer demonstrating three distinct panic variants (RS256, PS256, RSA-OAEP) with an ES256 control. Net: a genuine library defect worth patching on a routine cycle, but its real-world priority is gated by whether a downstream application actually exposes LoadPublicKey/LoadPrivateKey to attacker-controlled JWK input; against gose's documented verification path it is not reachable.

An application that uses gose and feeds externally supplied JWK documents (for example a caller-built JWKS loader) directly into the exported LoadPublicKey function receives a JWK of {"kty":"EC","alg":"RS256"} - well-formed per RFC 7517 §4.4. The kty-blind algorithm gate accepts it, the unchecked *ECDSAOptions type assertion fails, and the Go process panics, denying service. A working reproducer covering RS256/PS256/RSA-OAEP panic variants is published in the GHSA advisory.