Description

pac4j-oidc before 6.5.6 fails to verify access token signatures, issuers, audiences, or expiry when extracting Keycloak realm and client roles. Attackers can forge access tokens with administrative roles paired with valid ID tokens to bypass authorization checks in applications relying on pac4j role validation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-29T17:17:58.207Z",
  "pubdate": "2026-08-29T17:17:58.207Z",
  "executiveSummary": "The pac4j-oidc library, in versions prior to 6.5.6, contains a critical security vulnerability involving the improper validation of OpenID Connect (OIDC) access tokens. Specifically, the library fails to verify the integrity, authenticity, and temporal validity of access tokens when extracting Keycloak-specific realm and client roles. This flaw allows an attacker to bypass authorization logic by forging access tokens with elevated privileges. Because the system does not validate the signature, issuer, audience, or expiry of the presented token, an adversary can pair a fabricated access token containing malicious claims with a legitimately obtained ID token. This enables unauthorized escalation of privileges, potentially granting the attacker administrative access to protected resources. The risk is significant for applications relying on pac4j for fine-grained role-based access control (RBAC) in Keycloak-integrated environments, as it undermines the entire security posture of the authentication and authorization handshake.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the OIDC extraction logic within pac4j-oidc, specifically during the handling of Keycloak realm and client roles. When the library processes these roles, it fails to perform mandatory cryptographic and structural validation of the accompanying access token. In a standard OIDC flow, the access token must be validated against the Authorization Server's public key (signature verification), the 'iss' (issuer) claim, the 'aud' (audience) claim, and the 'exp' (expiration) timestamp before any claims—such as 'realm_access' or 'resource_access'—are parsed for authorization decisions.\nThe exploitation flow begins when an attacker identifies an application using a vulnerable version of pac4j-oidc integrated with Keycloak. The attacker obtains a valid ID token through legitimate authentication. However, the attacker crafts a malicious access token. Because the library omits signature verification, the attacker does not need the private key of the OIDC provider. They can construct a JSON Web Token (JWT) payload containing high-level administrative roles under the Keycloak-defined claim structures.\nWhen the application processes the authentication request, it fails to trigger the required validation checks on this forged access token. The library incorrectly trusts the claims contained within the token, believing them to be authenticated facts provided by the Identity Provider. Consequently, the application extracts the attacker-supplied, forged roles and updates the user's security context accordingly.\nThe impact is a complete bypass of the application's authorization mechanism. By manipulating the roles in the forged access token, an attacker can elevate their privileges to 'administrator' or other high-level roles recognized by the target application. This vulnerability does not require the attacker to compromise the OIDC provider; it relies entirely on the library's omission of standard JWT security assertions. The exposure is limited to systems where pac4j-oidc is configured to extract and rely upon role information from the access token for authorization purposes.\nThis vulnerability is particularly dangerous because the ID token remains valid (or is ignored during the malicious role extraction phase), allowing the attacker to pass initial identity verification while subverting the subsequent authorization checks that govern sensitive operations."
}