pac4j-oidc CVE-2026-82462

Exploitation targets any application using pac4j-oidc versions before 6.5.6 in an OIDC Authorization Code or hybrid flow configuration. The critical prerequisite is that the attacker must possess a valid access token issued by the same identity provider (IdP) that the target application trusts - this token may be for any registered OAuth client on that IdP, not necessarily the target application's own client_id. No prior authentication to the target application is required (CVSS PR:N/UI:N). Exploitation is meaningfully constrained in environments where the IdP enforces strict client isolation or where the target application is the only registered client; environments using major shared enterprise IdPs (Okta, Azure AD, Keycloak) with multiple registered clients present a wider attack surface because an attacker may legitimately hold tokens from any of those clients. OIDC deployments using only the implicit flow with mandatory ID token delivery, or where the callback endpoint is behind a WAF rejecting access-token-only requests, are not exploitable via this specific code path.

The CVSS 4.0 score of 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N) correctly reflects that the attack is remotely exploitable without privileges or user interaction, though the per-session impact metrics of Low confidentiality and Low integrity understate the systemic severity of a broken authentication boundary. The absence of a CISA KEV listing and no publicly identified POC or EPSS score in the available data means exploitation likelihood must be inferred from vulnerability class rather than observed activity - authentication bypass flaws in OIDC libraries targeting shared identity providers are attractive targets, particularly in multi-tenant enterprise SSO environments where multiple OAuth clients share a single IdP. The attack complexity is genuinely low: an attacker needs only to obtain a legitimately issued access token for any client registered with the same IdP, which can be accomplished by controlling or authenticating through any other application on that provider. Compensating controls exist (WAF callback filtering, strict IdP client registration policies) and reduce risk meaningfully. The vendor patch is confirmed and targeted - upgrade to 6.5.6 resolves the issue cleanly. Overall priority should be elevated above the raw numeric score for organizations running shared enterprise IdPs with multiple OIDC clients, where the trust boundary is wider and token acquisition is more feasible.

An attacker authenticates through a separate, attacker-controlled OAuth client registered on the same identity provider trusted by the target pac4j application, obtaining a legitimately issued access token for their own client. They construct an OIDC callback HTTP request to the vulnerable application's callback endpoint, embedding the access token in place of an authorization code or ID token. Because pac4j-oidc before 6.5.6 does not validate issuer, audience, nonce, or subject on access-token-only callbacks, the application creates an authenticated session - potentially resolving to a victim's identity if the access token carries a matching subject claim.