jwcrypto EUVD-2026-80228

Exploitation requires that the target application exposes a code path where an unauthenticated remote party can supply a JWK (or JWK Set) that is passed to jwcrypto's JWK.import_key(). Concrete exposure surfaces include: OIDC dynamic client registration endpoints where the registering client submits its own public key; ECDH-ES key agreement parsing where the ephemeral public key is included in attacker-controlled input; DPoP proof header parsing where the client-provided public key is extracted and imported; and ACME account key registration where the client's JWK is accepted before authentication. Applications that only import keys from local configuration files, HSMs, or pre-registered trusted sources are not exploitable. Authentication is not required (PR:N) when the vulnerable path is exposed via a public API, but the AC:H vector correctly reflects the deployment-context requirement that such a path must exist and accept external JWK material without prior input sanitisation.

The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, score 5.9) is reasonable and I assess it as accurate. AC:H is the key moderating factor: the attack requires an application to expose a code path that accepts externally-supplied JWK material and feeds it to import_key() without sanitisation - not all deployments of jwcrypto do this, but those that enable OIDC dynamic client registration, ACME key registration, or DPoP token processing do so inherently. No KEV listing and no public exploit have been identified, which is consistent with the Medium CVSS score. No EPSS data was provided in the input. Real-world risk is deployment-context dependent: an OIDC provider or ACME CA built on jwcrypto is directly exposed with no authentication barrier, while a service that only imports keys from configuration files or trusted internal sources has no practical exposure. The impact is strictly availability; there is no confidentiality or integrity dimension.

An attacker targeting an OIDC provider that supports dynamic client registration (RFC 7591) submits a registration request containing a JWK with key_ops populated with ten thousand identical string entries. The provider's library calls import_key() on the submitted JWK, triggering approximately 100 million pairwise comparisons; at reasonable CPU costs this consumes several seconds per request. By sending a modest stream of such requests - well within typical rate limits - the attacker saturates server CPU and denies service to legitimate authentication flows. No public exploit code is known, but the attack requires only a crafted JSON payload and is trivially constructible from the description.