CVE-2026-40458: Pac4j CSRF Token Collision Vulnerability

CVE-2026-40458 Overview

PAC4J is vulnerable to Cross-Site Request Forgery (CSRF) due to a fundamental weakness in how CSRF tokens are validated. A malicious attacker can craft a specially designed website which, when visited by a user, will automatically submit a forged cross-site request with a token whose hash collides with the victim's legitimate CSRF token. The vulnerability exploits collisions in the deterministic String.hashCode() function, which can be computed directly, effectively reducing the token's security space to just 32 bits.

Critical Impact

This vulnerability bypasses CSRF protection entirely, allowing attackers to perform profile updates, password changes, account linking, and any other state-changing operations without the victim's consent.

Affected Products

• PAC4J versions prior to 5.7.10
• PAC4J versions prior to 6.4.1
• All applications using vulnerable PAC4J CSRF protection mechanisms

Discovery Timeline

• 2026-04-17 - CVE-2026-40458 published to NVD
• 2026-04-20 - Last updated in NVD database

Technical Details for CVE-2026-40458

Vulnerability Analysis

This Cross-Site Request Forgery vulnerability stems from a cryptographic weakness in PAC4J's CSRF token validation mechanism. The security library relies on Java's String.hashCode() method to compare CSRF tokens, which is a deterministic 32-bit hash function. This design decision dramatically reduces the effective entropy of the CSRF protection from potentially hundreds of bits (depending on token length) to merely 32 bits.

The attack is particularly dangerous because it does not require the attacker to know the victim's actual CSRF token or its hash value prior to launching the attack. Instead, attackers can precompute hash collisions offline and embed malicious tokens that will match any legitimate user's CSRF token hash when the comparison is performed server-side.

Root Cause

The root cause lies in the use of String.hashCode() for CSRF token validation rather than a secure constant-time comparison of the actual token values. Java's String.hashCode() produces a 32-bit integer hash, which has a limited output space of approximately 4.3 billion possible values. For CSRF tokens, this creates a collision-prone validation mechanism where two completely different strings can produce the same hash value.

Attackers can precompute strings that hash to any desired 32-bit value, allowing them to generate forged CSRF tokens that will pass the hash-based validation check despite being entirely different from the victim's legitimate token.

Attack Vector

The attack is network-based and requires user interaction—specifically, the victim must visit an attacker-controlled website while authenticated to the vulnerable application. The attack flow involves:

1. The attacker identifies an application using a vulnerable PAC4J version for CSRF protection
2. The attacker precomputes a set of CSRF token values that produce hash collisions covering the entire 32-bit hash space
3. The attacker creates a malicious website containing hidden forms that submit forged requests to the target application
4. When the victim visits the malicious site, JavaScript automatically submits the form with the collision-generating CSRF token
5. The PAC4J validation compares hashes rather than actual token values, allowing the forged request to pass validation
6. The state-changing operation (password change, profile update, account linking) executes with the victim's authenticated session

Detection Methods for CVE-2026-40458

Indicators of Compromise

• Unexpected profile modifications or password changes reported by users who visited external websites
• Unusual patterns of account linking or OAuth authorization requests
• CSRF validation logs showing successful validations with tokens that don't match stored session tokens
• Multiple state-changing operations originating from unusual referrer domains
• User complaints of unauthorized actions being performed on their accounts

Detection Strategies

• Review application logs for CSRF token validation events and cross-reference with session token storage to identify hash collision attacks
• Implement referrer header validation as an additional layer to detect requests originating from suspicious external domains
• Monitor for abnormal patterns of state-changing requests that occur immediately after users navigate from external sites
• Deploy web application firewall rules to flag requests with CSRF tokens that appear in known collision lists

Monitoring Recommendations

• Enable detailed logging on all CSRF-protected endpoints to capture token values and validation outcomes
• Set up alerts for authentication-related state changes (password resets, email changes) that correlate with external referrer domains
• Monitor PAC4J library versions across your application portfolio to ensure vulnerable versions are identified
• Implement user activity notifications for sensitive account changes to enable rapid detection of unauthorized modifications

How to Mitigate CVE-2026-40458

Immediate Actions Required

• Upgrade PAC4J to version 5.7.10 or later for the 5.x branch
• Upgrade PAC4J to version 6.4.1 or later for the 6.x branch
• Review application logs for any suspicious CSRF-related activity that may indicate prior exploitation
• Consider implementing additional CSRF protections such as SameSite cookie attributes and origin header validation
• Notify users to review recent account changes and reset passwords if unauthorized modifications are suspected

Patch Information

The PAC4J development team has released security patches that address this vulnerability. Version 5.7.10 and 6.4.1 implement proper constant-time comparison of CSRF token values instead of relying on String.hashCode() comparisons. Organizations should update to these patched versions as soon as possible.

For detailed patch information, refer to the Pac4j Security Advisory and the CERT Polska advisory.

Workarounds

• Implement additional CSRF defenses at the application layer, such as requiring re-authentication for sensitive operations
• Enable SameSite cookie attributes set to Strict or Lax to prevent cookies from being sent in cross-origin requests
• Add custom validation logic that performs byte-by-byte token comparison rather than relying solely on PAC4J's built-in validation
• Deploy web application firewall rules to block requests with known collision-generating token patterns
• Implement origin and referrer header validation as supplementary CSRF protection

# Maven dependency update example for PAC4J 6.x
# Update pom.xml to specify the patched version
# <dependency>
#   <groupId>org.pac4j</groupId>
#   <artifactId>pac4j-core</artifactId>
#   <version>6.4.1</version>
# </dependency>

# For Gradle users (build.gradle)
# implementation 'org.pac4j:pac4j-core:6.4.1'