CVE-2026-41707 in Spring Security
Summary
by MITRE • 08/26/2026
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. Spring Security 7.1.0 Spring Security 7.0.0 - 7.0.6 Spring Security 6.5.0 - 6.5.11
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Spring Security involves a cache-based replay attack within the DPoPProofJwtDecoderFactory component, specifically affecting versions 7.1.0 and ranges including 7.0.0 through 7.0.6 as well as 6.5.0 through 6.5.11. This flaw stems from an implementation detail in how the framework manages state for Delegates Proof of Possession tokens, a mechanism designed to bind OAuth2 access tokens to specific client instances using cryptographic proofs. The internal cache responsible for storing JWT ID claims used to track previously seen proof identifiers has a strict size limit that is insufficiently large or improperly managed relative to potential attack volumes. This architectural limitation creates an opportunity for denial of service and authentication bypass through resource exhaustion techniques, fundamentally undermining the security guarantees provided by DPoP bindings.
From a technical perspective, the vulnerability allows attackers to exploit the finite capacity of the cache storing JWT ID claims. By flooding the server with dummy requests containing unique but invalid or non-existent proof identifiers, an attacker can systematically fill and overflow this internal data structure. Because the cache operates on a least-recently-used eviction policy typical of such implementations, legitimate entries representing valid DPoP proofs from authorized clients are evicted to make room for the malicious dummy entries. Once these legitimate entries are removed from the cache, the security mechanism that prevents replay attacks is effectively disabled for those specific tokens or sessions. This state manipulation allows an attacker who has intercepted a valid DPoP proof from a previous session to reuse it later without detection, as the system no longer recognizes the identifier as already processed due to its removal from the tracking store.
The operational impact of this vulnerability is significant, encompassing both availability and integrity concerns. The initial phase of the attack serves as a denial-of-service vector by consuming server resources through high-volume request processing, potentially degrading service performance for legitimate users. More critically, once the cache state is manipulated, the integrity of authentication flows is compromised. An attacker can replay intercepted DPoP proofs to impersonate valid clients or access protected resources without possessing the current cryptographic proof required by a secure implementation. This bypasses the intended binding between the client and the token, allowing unauthorized actions under the guise of legitimate user sessions. The severity is heightened in environments where session fixation or token interception is feasible, as it transforms transient network captures into persistent authentication credentials.
This vulnerability aligns with CWE-203, which describes a response that does not properly prevent replay attacks, and falls under MITRE ATT&CK technique T1588, specifically the sub-category of Obtain Capabilities: Credentials due to the potential for credential reuse through cache manipulation. It also relates to CWE-400 regarding uncontrolled resource consumption during the denial-of-service phase. To mitigate this risk, organizations should upgrade immediately to a patched version of Spring Security that addresses the cache size limitations or implements more robust eviction policies and rate limiting mechanisms. Additionally, implementing strict request rate limiting at the network perimeter can help prevent the flooding required to trigger the cache overflow. For applications where DPoP is critical, ensuring that token binding checks are not solely reliant on in-memory caches but include persistent storage with appropriate capacity planning is essential for maintaining security posture against such state-based attacks.