pac4j-core CVE-2026-82463

The application must use pac4j-core's CheckProfileTypeAuthorizer to enforce profile-type-based access control - this is the specific, non-default configuration required for exploitation. The attacker must have valid credentials for any authentication client supported by the application (PR:L); unauthenticated access is not possible. Exploitation is limited to resources explicitly protected by CheckProfileTypeAuthorizer configured with a specific subtype (e.g., OidcProfile, SamlProfile, or a custom subclass); resources protected only by standard role-based or permission-based authorizers are unaffected. Applications that authenticate all users through a single client type producing identical profile classes are also unaffected, as no meaningful type distinction exists to bypass.

The CVSS 4.0 score of 8.6 with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N reflects a high-severity but not maximally critical issue: network-exploitable, low complexity, but requiring prior authentication (PR:L). The practical risk is significant for applications that rely on CheckProfileTypeAuthorizer to distinguish access tiers - for example, allowing API access only to SAML-authenticated users while excluding form-login users. Any application not using this specific authorizer class is unaffected. No EPSS data was provided; no KEV listing exists, and no public exploit has been identified at time of analysis. The risk is real but narrowly scoped to deployments that have implemented profile-type-based access control using pac4j's CheckProfileTypeAuthorizer. The fix was bundled with five other security improvements in the same 6.5.6 release, suggesting these were discovered and patched together rather than in response to observed exploitation.

An attacker registers or already holds credentials for a weaker authentication path - for example, a form-login account that produces a CommonProfile - in an application that also supports SAML SSO producing a SamlProfile for privileged users. The attacker authenticates via the weaker client and then requests a resource guarded by CheckProfileTypeAuthorizer configured to require SamlProfile; due to the inverted check, the authorizer returns true for the CommonProfile and grants access to the protected resource. No public exploit code has been identified, but the logic inversion is straightforward to reproduce from the public commit diff.