Eclipse KeyPont gose CVE-2026-89314

Exploitation requires that the gose consumer parse a JWK/JWKS document originating from an attacker-controlled or attacker-influenced source, because CheckConsistency runs on every JWK and JWKS unmarshal. Concretely, the attacker must be the operator of (or a TLS-terminating MITM against) the configured JWKS endpoint, or the application must accept a JWKS/discovery URL as user input, or the discovery URL must be misconfigured to point at an untrusted host. The malicious payload is a single JWKS body under 1 MB containing roughly 100,000 distinct (non-duplicate, so no early loop exit) key_ops values on one key. LIMITING FACTORS: the advisory states this is NOT remotely triggerable against a correctly configured deployment that points at a trusted identity provider, so a deployment pinned to a trusted IdP is not exposed; a response-body size cap is only a partial mitigation because the quadratic factor makes even small bodies disproportionately expensive. No authentication of the attacker and no user interaction are required once the victim fetches from the hostile endpoint.

This is a genuine but modest-severity algorithmic-complexity DoS (CWE-407), and the signals are internally consistent rather than conflicting. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L) scores 6.9 and treats the flaw as remotely and trivially reachable with only low availability impact, but the vendor advisory materially qualifies that attack vector: it states the bug 'is not remotely triggerable against a correctly configured deployment pointing at a trusted identity provider' and is only reachable when the consumer fetches a JWKS from an attacker-controlled or attacker-influenced endpoint (malicious/compromised IdP, misconfigured discovery URL, or an application that accepts a JWKS URL as user input). So the AC:L/AT:N encoding overstates real-world reachability - the true precondition is control or MITM of the configured JWKS source, which is a non-default trust condition. No CISA KEV listing and no EPSS score are present in the input, and no active exploitation is claimed; the only exploitation signal is the GHSA advisory itself, which ships a runnable reproducer. The vuln.today decision label is 'this_month' (not act_now/emergency), matching the Low vendor severity. Net: a real, confirmed, patch-worthy issue but a lower-priority one - the impact is a single CPU core pinned for ~15 s per sub-1 MB request, availability-only, gated behind a trust-boundary precondition that correctly-configured deployments do not meet. Note the input Tags label this 'Information Disclosure,' which directly contradicts the advisory's explicit 'No confidentiality or integrity impact' - treat that tag as erroneous.

An application using eclipse-keypont/gose (or the deprecated ThalesGroup/gose) is configured - or tricked via a user-supplied or misconfigured discovery URL - to fetch a JWKS from an endpoint the attacker controls or can MITM. The attacker serves a sub-1 MB JWKS whose key contains tens of thousands of distinct, junk key_ops values; the quadratic duplicate-check in jwkFields.CheckConsistency runs to completion and pins one CPU core for roughly 15 seconds per parse. A public proof-of-concept reproducer demonstrating the quadratic timing is published in the GHSA advisory.