pac4j-oidc CVE-2026-82461

Exploitation requires three specific conditions: (1) the target application uses pac4j-oidc's KeycloakRolesAuthorizationGenerator specifically - general OIDC flows not using this generator are unaffected; (2) Keycloak is configured as the OpenID Connect identity provider; (3) the attacker possesses a valid Keycloak account sufficient to obtain a legitimate ID token (PR:L per CVSS 4.0 vector). The ID token itself is not bypassed and must be authentic - only the access token's role claims go unvalidated. Exploitation is limited to the Keycloak-specific role extraction code path; applications using pac4j with non-Keycloak IdPs, or those using alternative role authorization strategies, are not affected. The CVSS PR:L constraint is a meaningful limiting factor: environments with self-registration disabled and controlled identity issuance substantially reduce real-world risk.

The vendor-provided CVSS 4.0 score of 8.6 accurately reflects the severity: the attack is network-reachable (AV:N), low complexity (AC:L), requires no special attack conditions (AT:N), but does require low-level privileges (PR:L) - the attacker must possess a legitimate Keycloak user account to obtain a valid ID token. High confidentiality and integrity impacts (VC:H/VI:H) are warranted given that successful exploitation grants self-assigned administrative roles across all pac4j-protected resources. No EPSS data was provided; the absence of KEV listing and public POC tempers the immediacy of exploitation risk, though the attack mechanism is conceptually straightforward for any OIDC-familiar attacker. The most important limiting factor is PR:L: unauthenticated external attackers cannot exploit this without first compromising or registering a Keycloak account. Organizations where guest or self-registration is enabled face meaningfully higher real-world risk than those with tightly controlled identity issuance.

An attacker with a low-privilege Keycloak account completes a normal OIDC login to obtain a legitimate ID token. They then craft a separate unsigned (or arbitrarily signed) access token containing Keycloak realm role claims such as realm_access.roles: ["admin"] and submit this forged token alongside their valid ID token to a pac4j-protected application endpoint. Because pac4j's KeycloakRolesAuthorizationGenerator extracts roles without validating the access token's signature or claims, the fabricated admin roles are trusted and added to the user profile, granting full administrative authorization bypass.