PAC4J patches CSRF token hash-collision bypass

TL;DR — PAC4J’s CSRF protection can be bypassed by precomputing String.hashCode() collisions, letting attackers forge state-changing requests when a victim visits a malicious page.

What happened

PAC4J is a Java security engine used to implement authentication/authorization across JVM web stacks via libraries like pac4j-core. CVE-2026-40458 describes a CSRF protection bypass where an attacker can submit a forged cross-site request using a token whose hash collides with the victim’s legitimate CSRF token.

The CVE states that collisions in Java’s deterministic String.hashCode() can be computed directly, effectively reducing the token’s security space to 32 bits and enabling CSRF bypass for state-changing actions (e.g., profile updates, password changes, account linking). CISA’s ADP enrichment for this record lists “Exploitation: none” at publication time, but CSRF weaknesses in shared security middleware are high-leverage because they can scale across many services that “inherit” the same protection layer.

Who is impacted

• Applications using PAC4J CSRF support in the affected 5.x or 6.x version ranges below (per the CVE record).
• Any environment where authenticated users can be induced to load attacker-controlled content (the standard CSRF precondition).

What to do now

• Follow vendor remediation guidance and update to a PAC4J release that includes the fix.

  "This issue was fixed in PAC4J versions 5.7.10 and 6.4.1"

• Inventory services that depend on pac4j-core (directly or transitively) and confirm deployed versions via build manifests, lockfiles, and container images.
• Review high-impact state-changing routes protected by CSRF controls (password/email change flows, account linking, admin actions) and validate that additional server-side invariants exist where appropriate (e.g., step-up auth for sensitive changes).
• If suspicious account changes are suspected, triage server logs for browser-originated state-changing requests and invalidate sessions / rotate impacted credentials per your incident response playbooks.