pac4j 6.5.6 closes a forged Keycloak role-token path
Applications that use pac4j to map Keycloak roles should upgrade after a high-severity OIDC authorization flaw exposed unchecked access-token claims.
pac4j has issued a security update for its core, OpenID Connect and SAML modules, telling users to move to version 6.5.6. For application teams that use pac4j to translate Keycloak claims into roles, one of the disclosed flaws is a direct authorization risk rather than a generic hardening change.
What changed
The project’s August security advisory says security fixes and hardening landed in pac4j 6.5.6 and explicitly recommends upgrading pac4j-core, pac4j-oidc for OIDC deployments and pac4j-saml for SAML deployments. The project did not publish technical details in that post.
The linked GitHub advisory for CVE-2026-82461 supplies the important OIDC detail: pac4j-oidc before 6.5.6 did not verify access-token signatures, issuers, audiences or expiry when extracting Keycloak realm and client roles. According to the advisory, an attacker with a valid ID token could pair it with a forged access token carrying administrative roles and bypass authorization checks in applications that rely on pac4j role validation.
GitHub currently labels the record unreviewed and lists no package metadata, but rates the issue high severity at CVSS 8.6. Its vector describes a network-reachable attack with low privileges, low complexity and no user interaction.
Who is affected
This is not a vulnerability in Keycloak itself. The failure is in pac4j’s handling of access-token claims when applications use its Keycloak role extraction path. Teams that operate Keycloak should therefore focus on the client applications and services that consume those roles through pac4j, especially deployments running pac4j-oidc earlier than 6.5.6.
The project’s broader advisory also calls for upgrades to the core and SAML modules, so treating this as an OIDC-only maintenance event would miss the rest of the release’s security scope.
What to do
Application owners should inventory pac4j dependencies, update the relevant modules to 6.5.6 and redeploy affected services. For OIDC applications, the immediate review target is any authorization logic that derives Keycloak realm or client roles through pac4j. Teams should also check whether dependency-management layers or framework integrations pin an older pac4j version rather than assuming a top-level application update pulled in the fix.
Because the project withheld additional exploit details, the practical response is the one its advisory states plainly: use the latest mature version and apply the security update promptly.
sources
comments · 0