Description

Authentication Bypass by Capture-replay vulnerability in Spring Spring Security allows Spring Security's DPoPProofJwtDecoderFactory contains a cache-based replay attack vulnerability. The internal cache storing JWT ID claims has a strict size limit, allowing attackers to evict legitimate entries by flooding the server with dummy requests, then replay intercepted valid DPoP proofs. This issue affects Spring Security: 7.1.0, from 7.0.0 through 7.0.6, and from 6.5.0 through 6.5.11.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-08-25T23:16:59.933Z",
  "pubdate": "2026-08-25T23:16:59.933Z",
  "executiveSummary": "This vulnerability is an authentication bypass via a capture-replay attack affecting the DPoP (Demonstrating Proof-of-Possession) implementation within Spring Security. The flaw resides in the DPoPProofJwtDecoderFactory component, specifically concerning its internal cache mechanism for tracking JWT ID (jti) claims.\nThe vulnerability allows an unauthenticated remote attacker to bypass DPoP proof validation by forcing the eviction of legitimate jti tokens from the cache. By flooding the application with requests containing dummy DPoP proofs, an attacker can displace valid, intercepted jti claims from the finite cache structure. Once the target claim is evicted, the attacker can successfully replay the previously intercepted valid DPoP proof, potentially gaining unauthorized access or impersonating a legitimate user session.\nThe issue affects Spring Security versions 7.1.0, 7.0.0 through 7.0.6, and 6.5.0 through 6.5.11. This represents a significant security risk as it undermines the integrity of proof-of-possession tokens, which are designed to mitigate replay attacks. Exploitation requires the attacker to be in a position to observe valid DPoP proofs and successfully perform a cache-flooding denial-of-service attack against the cache storage mechanism.",
  "technicalDetails": "The root cause of this vulnerability lies in the bounded nature of the internal cache utilized by the DPoPProofJwtDecoderFactory. To ensure that DPoP proofs are not reused, Spring Security tracks previously seen JWT ID (jti) claims within an in-memory cache. This cache is implemented with a strict size limit, which is intended to prevent memory exhaustion but fails to account for resource-exhaustion-based eviction attacks.\nThe attack flow follows a structured methodology to circumvent the replay protection logic:\n1. Interception: The attacker captures a legitimate DPoP proof transmitted by a victim client during a standard authentication or authorization flow.\n2. Cache Saturation: The attacker initiates a flood of requests, each containing unique, arbitrary, or dummy DPoP proofs. Because the cache used by DPoPProofJwtDecoderFactory has a finite size, these injected proofs force the eviction of entries following a specific replacement policy (such as Least Recently Used or First-In-First-Out).\n3. Eviction: The attacker sends enough requests to ensure the jti claim associated with the intercepted legitimate proof is purged from the cache memory.\n4. Replay: Once the valid jti is no longer present in the cache, the attacker transmits the previously captured, valid DPoP proof to the application. Because the verification logic relies exclusively on the presence of the jti in the cache to detect replays, and the entry has been successfully evicted, the application incorrectly validates the proof as legitimate.\nThe vulnerable component is identified as the DPoPProofJwtDecoderFactory. This flaw exposes the application to unauthorized actions if the DPoP proof is used to grant access to restricted resources. Because the cache does not differentiate between legitimate high-traffic volume and intentional cache-flooding, the defensive mechanism is bypassed through a side-channel manipulation of the validation state.\nThis vulnerability does not require prior authentication, provided the attacker can reach the endpoint responsible for DPoP proof validation. The post-exploitation impact includes the potential for session hijacking or unauthorized API access, depending on the scope of the token being validated. The architectural reliance on a simple size-limited cache for non-persistent security state management is the primary failure point in this implementation."
}