CVE-2026-82461 in pac4j-oidc
Summary
by MITRE • 08/29/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/29/2026
The vulnerability identified in versions of the pac4j-oidc library prior to 6.5.6 represents a critical failure in the implementation of OpenID Connect authentication flows, specifically concerning the validation of access tokens when extracting roles from Keycloak realms and clients. This flaw stems from an incomplete adherence to the security requirements outlined in RFC 7519 for JSON Web Tokens (JWT) and the specific specifications governing OIDC token handling. When applications utilize pac4j-oidc to authenticate users via identity providers such as Keycloak, the library is responsible for verifying that the access tokens presented by clients are legitimate, unaltered, and intended for the current application context. In the affected versions, this verification process is critically deficient because it omits essential checks on signature validation, issuer identification, audience restriction, and token expiration status during the extraction of role information.
From a technical perspective, the absence of signature verification means that an attacker can craft arbitrary JWTs without possessing the private key associated with the identity provider's signing algorithm. Normally, relying parties must verify the cryptographic signature to ensure the token was issued by a trusted authority and has not been tampered with in transit. By skipping this step, pac4j-oidc allows tokens generated by malicious actors to be processed as if they were authentic. Furthermore, the lack of issuer verification means that even if an attacker manages to generate a valid signature using a known public key or exploits another weakness, there is no check to confirm that the token actually originated from the expected Keycloak realm. Similarly, the failure to validate audience claims allows tokens intended for other services within the same identity provider infrastructure to be accepted by this application, facilitating cross-service attacks if multiple applications share trust relationships with the same issuer but have distinct access control policies.
The omission of expiry validation introduces a significant risk related to token lifecycle management. Without checking whether an access token has expired, attackers can reuse captured or forged tokens indefinitely, provided they remain valid under other criteria that might still be checked elsewhere in the application logic. This undermines the principle of least privilege and session expiration controls designed to limit the window of opportunity for unauthorized access. The combination of these missing validations creates a scenario where an attacker can forge an access token containing administrative roles while simultaneously presenting a valid ID token, which may undergo stricter validation checks depending on how the application is configured. Since many OIDC implementations prioritize ID token verification for authentication and rely on separate logic or assumptions for access token authorization, this discrepancy allows attackers to bypass role-based access control mechanisms entirely.
The operational impact of this vulnerability is severe, as it directly compromises the integrity of authorization decisions in applications relying on pac4j for security management. An attacker who successfully exploits this flaw can elevate their privileges by injecting administrative roles into forged tokens, thereby gaining unrestricted access to sensitive features, data, or configuration settings that should be restricted to authorized personnel. This type of attack aligns with Common Weakness Enumeration (CWE) categories such as CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity. It also maps to MITRE ATT&CK techniques including T1078 Valid Accounts, where attackers use legitimate-looking credentials or tokens to maintain persistent access, and potentially T1621 Multi-Factor Request Bypass if the forged token is used in conjunction with other bypassed multi-factor authentication steps.
To mitigate this vulnerability, organizations must immediately upgrade pac4j-oidc to version 6.5.6 or later, where these critical validation checks have been restored and hardened against such attacks. In addition to upgrading the library, developers should review their security configurations to ensure that all OIDC tokens are subjected to rigorous validation before any role extraction occurs. This includes implementing strict signature verification using appropriate algorithms like RS256 or ES256 rather than relying on weaker options if available, validating the iss claim against a whitelist of trusted issuers, ensuring the aud claim matches the client ID of the application, and strictly enforcing expiration times to prevent replay attacks. Regular security audits and static code analysis focused on authentication flows can help identify similar oversights in other parts of the system, reinforcing defense-in-depth strategies against token forgery and authorization bypass attempts.