Description

Several components in Spring Security compare security-sensitive values using standard string equality (String.equals()) rather than a constant-time comparison. Because String.equals() returns as soon as it finds a differing character, the time taken to reject an incorrect value is proportional to the number of leading characters that match the expected value. Spring Security 7.1.0 Spring Security 7.0.0 - 7.0.6 Spring Security 6.5.0 - 6.5.11 Spring Security 6.4.0 - 6.4.18 Spring Security 5.8.0 - 5.8.27 Spring Security 5.7.0 - 5.7.25

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-27T20:17:53.863Z",
  "pubdate": "2026-08-27T20:17:53.863Z",
  "executiveSummary": "A timing side-channel vulnerability exists in multiple versions of Spring Security due to the utilization of non-constant-time string comparison methods for sensitive security values. By employing standard String.equals() for cryptographic or authentication-related tokens, the framework introduces a measurable variance in execution time based on the prefix of the submitted input.\nThe vulnerability affects Spring Security versions 7.1.0, 7.0.0-7.0.6, 6.5.0-6.5.11, 6.4.0-6.4.18, 5.8.0-5.8.27, and 5.7.0-5.7.25. This flaw permits a remote attacker to perform timing analysis attacks to iteratively guess secrets, such as API keys, authentication tokens, or other sensitive identifiers.\nSuccessful exploitation allows an attacker to bypass security controls or impersonate valid users without possessing the actual secret. The risk is significant in environments where secrets are compared against user-supplied input. There are no specific complex prerequisites beyond the ability to measure response times over a network, although network jitter can complicate the statistical analysis required for a successful attack.",
  "technicalDetails": "The root cause of this vulnerability is the use of the Java String.equals() method for comparing security-sensitive strings. In the Java implementation, String.equals() performs a character-by-character comparison that terminates immediately upon encountering the first mismatching character. This behavior creates a measurable timing difference: the longer the prefix of the submitted string matches the expected secret, the longer the method takes to return a boolean result.\nWhen an application utilizes this comparison logic to validate tokens, passwords, or signatures, an attacker can exploit this temporal leakage. By sending a large number of requests with varying prefixes, an attacker can statistically infer the correct character at each position by observing the median response time variations. Each successful byte identification effectively reduces the entropy of the secret, enabling a systematic reconstruction of the entire value.\nThe attack flow follows a iterative process: 1. The attacker monitors network latency to establish a baseline. 2. The attacker submits candidate strings, observing the timing measurements for each request. 3. Through statistical methods, such as calculating the standard deviation or median latency, the attacker identifies the string that produces a slightly longer execution time, indicating a correct character match. 4. This process is repeated position-by-position until the complete sensitive string is recovered.\nThis vulnerability is particularly critical in components responsible for validating authentication credentials or integrity-checked tokens. Because String.equals() is a standard library function, any internal Spring Security logic relying on this for critical path comparisons is inherently susceptible to this side-channel. The exposure is network-based; any interface that performs a comparison against an input parameter is a potential vector.\nThe impact includes unauthorized authentication, session hijacking, or the potential for bypassing cryptographic checks. The vulnerability persists across several major branches of Spring Security, spanning versions 5.7.x through 7.1.0. Mitigation requires transitioning from non-constant-time comparison primitives to dedicated cryptographic comparison functions, such as MessageDigest.isEqual(), which ensures that the comparison operation consumes a fixed duration regardless of the content of the input strings."
}