jwcrypto EUVD-2026-70747

Exploitation requires the attacker to hold a valid cryptographic key that is registered within the same JWK set used by the target application - this is the primary limiting prerequisite (AC:H, PR:L). The target application must use jwcrypto to verify General JSON Serialization JWS tokens and must rely on the kid field to enforce per-tenant, per-user, or per-service authorization boundaries; applications that use compact JWS serialization or that do not perform kid-based access control are not affected by the authorization-bypass impact. The attacker must be able to present a crafted token to an endpoint that calls jwcrypto's multi-key verification path. Applications that enforce authorization through entirely separate mechanisms (e.g., separate JWK sets per tenant rather than a shared set with kid routing) are not vulnerable. Network access to an endpoint that consumes JWS tokens is required.

The provided CVSS vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N is well-calibrated. AC:H correctly reflects that exploitation requires the attacker to already possess a valid key within the target application's JWK set - a non-trivial prerequisite. PR:L reflects the baseline credential (key) needed to participate in the JWK set. The high integrity score (I:H) is justified because successful exploitation enables full cross-tenant or cross-user authorization bypass, which is a severe business logic violation. The low confidentiality score (C:L) reflects that the attacker may gain access to data belonging to the impersonated party but does not directly exfiltrate cryptographic material. Real-world risk is significant in multi-tenant SaaS deployments and platform-as-a-service environments (Ansible, OpenShift) that use kid-based audience segregation for their service tokens. Risk is considerably lower in single-tenant or single-key configurations. No public exploit code or KEV listing exists at time of analysis, and the EPSS signal is absent from the provided data.

An attacker who has been legitimately issued a cryptographic key as tenant B within a multi-tenant Ansible Automation Platform or OpenShift AI deployment crafts a General JSON Serialization JWS token. They sign the payload with their own key B but set the 'kid' field in the protected header to tenant A's key identifier. When jwcrypto verifies this token, it accepts the signature because key B is valid within the shared JWK set, ignoring the kid mismatch. The attacker is then granted tenant A's privileges and can read or modify tenant A's data, pipelines, or AI workloads. No public proof-of-concept code has been identified, but the technique is straightforward to implement for any holder of a valid key.