CVE-2026-82462 in pac4j
Summary
by MITRE • 08/29/2026
pac4j-oidc before 6.5.6 accepts OIDC callbacks carrying only an access token without authorization code or ID token validation. Attackers can substitute access tokens minted for other clients to create authenticated sessions without proper issuer, audience, nonce, or subject verification.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/29/2026
The vulnerability in pac4j-oidc versions prior to 6.5.6 represents a critical failure in the OpenID Connect authentication flow, specifically within the handling of authorization code exchange and token validation processes. The core technical flaw lies in the library's acceptance of OIDC callbacks that contain only an access token while omitting the required ID token or failing to validate it against security standards. In a standard OIDC implementation, the identity provider issues both an access token for resource access and an ID token containing claims about the authenticated user. The relying party must verify these tokens to establish trust. However, this vulnerability allows attackers to bypass the rigorous validation steps by submitting callbacks with just an access token. This deviation from the protocol enables a scenario where the application accepts authentication based solely on possession of a valid-looking access token, ignoring essential cryptographic and semantic checks that are fundamental to secure identity federation.
The operational impact of this flaw is severe, as it permits unauthorized session creation through token substitution attacks. An attacker can intercept or obtain an access token intended for a different client application within the same ecosystem or even from a public issuer if configuration allows loose validation. By substituting these tokens into the authentication callback, the attacker tricks the pac4j-oidc implementation into establishing a new authenticated session under their identity without possessing the correct secret keys or passing through proper authorization flows. The absence of verification for critical fields such as the issuer (iss), audience (aud), nonce, and subject (sub) means that standard protections against replay attacks, cross-client token misuse, and impersonation are effectively disabled. This leads to a complete compromise of authentication integrity, allowing attackers to assume identities of legitimate users or escalate privileges by leveraging tokens minted for other services.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to adequately verify the identity of the user during the login process. It also relates closely to CWE-345 Insufficient Verification of Data Authenticity and CWE-613 Insufficient Session Expiration, given that session tokens are accepted without proper validation against their intended scope or origin. In terms of MITRE ATT&CK framework techniques, this exploit maps directly to T1078 Valid Accounts, where attackers use legitimate credentials or tokens obtained from other sources to gain access. Furthermore, the mechanism of substituting tokens for different clients reflects aspects of T1528 Steal Application Access Token, highlighting how misconfigured OIDC providers can become vectors for identity theft and lateral movement within an organization's infrastructure.
Mitigation strategies must focus on enforcing strict compliance with OpenID Connect specifications. Organizations running pac4j-oidc versions before 6.5.6 should immediately upgrade to version 6.5.6 or later, where the library enforces mandatory validation of ID tokens and associated claims. Administrators should also review their OIDC provider configurations to ensure that only authorized clients are permitted to request tokens and that callback URLs are strictly whitelisted. Implementing additional security layers such as mutual TLS for token endpoints and enforcing strict audience verification can further reduce the risk surface. Regular audits of authentication logs for anomalous patterns, such as multiple session creations from different origins using similar token structures, can help detect potential exploitation attempts in real-time before significant damage occurs.