oidcc CVE-2026-75759

Exploitation requires three concurrent conditions: (1) the target application runs oidcc versions 3.2.0-beta.1 through before 3.9.0; (2) the OpenID Provider or relying party configuration enables encrypted ID tokens (id_token_encryption_alg_values_supported is set, e.g., to RSA-OAEP) or JARM is in use for authorization responses; and (3) the attacker can obtain the relying party's public encryption key, which in standard deployments is publicly accessible via the JWKS URI. User interaction is required: the victim must initiate a legitimate authentication flow through the relying party, as the forged token must be delivered through the browser front-channel callback. Exploitation is NOT possible against the UserInfo endpoint (explicitly excluded by the OpenID Connect specification and confirmed in the vendor advisory), against deployments using signed-only ID tokens (no encryption configured), or against oidcc versions before 3.2.0-beta.1 or 3.9.0 and later.

The CVSS 4.0 score of 7.6 (AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N) captures a network-reachable, unauthenticated flaw with high confidentiality and integrity impact, tempered by two limiting factors: AT:P (specific attack prerequisites - encrypted token support must be configured) and UI:P (victim must initiate an authentication flow). In practice, the AT:P constraint is weaker than it appears: OpenID Connect relying parties routinely publish their JWKS endpoint publicly, meaning the encryption key an attacker needs is freely accessible in any standard deployment that supports ID token encryption. The UI:P constraint is also inherent to browser-based OAuth/OIDC flows and should not be treated as a meaningful barrier for targeted attacks. No EPSS score was provided in the input data; no CISA KEV listing is present, and no public POC was referenced, indicating no confirmed active exploitation at time of analysis. The impact is critical for any deployment using encrypted ID tokens or JARM (common in FAPI 2.0 and financial-grade API contexts, as suggested by the test fixtures referencing FAPI 2.0 client contexts), but deployments using signed-only ID token flows are entirely unaffected. The absence of a public exploit and the narrow deployment surface (Erlang/Elixir ecosystem, encrypted token feature enabled) suggest moderate real-world urgency, though the authentication bypass impact justifies priority patching where the feature is in use.

An attacker retrieves the relying party application's public encryption key from its published JWKS endpoint, then constructs a JWE token containing fabricated claims (sub set to the target victim's user identifier, iss set to the legitimate provider's issuer URL, aud set to the relying party's client ID) without applying any nested signature. The attacker delivers this token through the browser front-channel authentication callback - for example, as a JARM-encoded authorization response - and oidcc, in vulnerable versions, decrypts the token and returns the unsigned claims as fully validated, granting the attacker a session as the impersonated user.