CVE-2026-41710

What it actually does

CVE-2026-41710 is a denial-of-service flaw in Spring Retry affecting versions 2.0.0 through 2.0.12 and 1.3.0 through 1.3.4. An unauthenticated network attacker can send many unique requests that intentionally fail in code paths using stateful retry. Each unique failure can consume an entry in the application-wide stateful retry cache. When that cache reaches capacity, it stops accepting further updates, which can cause subsequent stateful retries and circuit-breaker behavior across the application to fail. The primary impact is availability loss; confidentiality and integrity are not directly affected. The CVSS score is 5.9 with high attack complexity, EPSS is low at 0.0028 and flat over 30 days, and there is no current CISA KEV listing or known ransomware association.

Why it matters to the business

Successful exploitation can degrade or break application resilience mechanisms that normally help services recover from transient failures. In practical terms, applications may start failing requests that would normally be retried, downstream service interruptions can become more visible to users, and operational teams may see cascading reliability issues until the application is restarted or remediated. Because Spring Retry is commonly embedded as a library dependency, exposure may exist through direct or transitive dependencies even when teams do not explicitly deploy a standalone Spring Retry component. Current public exploitation signals are low, but internet-facing applications or APIs that use stateful retry on attacker-controllable inputs should be prioritized.

How an attack unfolds

An attacker first identifies an application endpoint that triggers Spring Retry stateful retry behavior when requests fail. The attacker then sends a large number of requests with unique retry keys or unique request attributes while causing those requests to fail. Because the retry cache treats the requests as distinct retry contexts, each request consumes additional cache capacity. Once the application-wide cache is exhausted, the cache rejects further updates. From that point forward, legitimate retry and circuit-breaker workflows that depend on that cache can fail, causing request failures, degraded service reliability, or broader application instability. Recovery may require upgrading, configuration changes, and restarting affected application instances to clear the poisoned cache state.

How to fix it

Upgrade Spring Retry to a fixed version outside the affected ranges. Versions 2.0.0 through 2.0.12 and 1.3.0 through 1.3.4 should be treated as vulnerable; use the vendor-advised fixed release for the relevant branch, and validate both direct and transitive dependencies in Maven, Gradle, container images, and packaged application artifacts. If immediate upgrade is not possible, reduce exposure by disabling stateful retry where it is not required, replacing the default retry context cache with a bounded cache that has safe eviction/TTL behavior, limiting attacker control over retry keys, adding request rate limits, enforcing input validation, and applying WAF/API-gateway throttling to endpoints that can trigger retry failures. Restart affected application instances after remediation or mitigation to clear exhausted in-memory cache state.

How to confirm the fix worked

Confirm that no deployed artifact contains Spring Retry versions 2.0.0 through 2.0.12 or 1.3.0 through 1.3.4. Use dependency inspection such as Maven dependency trees, Gradle dependency reports, SBOMs, SCA tooling, container image scans, and inspection of packaged JAR metadata such as pom.properties and MANIFEST.MF. In a non-production test environment, exercise known stateful retry paths and verify that repeated unique failing requests do not permanently exhaust retry cache capacity and that normal retries and circuit breakers continue to function. After patching, validate application logs no longer show retry cache capacity exceptions, and confirm application health metrics, retry metrics, circuit-breaker metrics, and error rates remain stable under controlled failure testing.

Typical attack path

1. Identify an application or API that uses affected Spring Retry versions and has stateful retry enabled on a reachable code path.
2. Find request parameters, headers, payload values, or workflow attributes that influence the retry cache key or create unique retry contexts.
3. Generate many distinct requests that intentionally trigger failures in the stateful retry path.
4. Fill the application-wide stateful retry cache with unique failed retry contexts.
5. Cause the cache to reject further updates once capacity is exhausted.
6. Leverage the resulting failure of stateful retries and circuit breakers to degrade application availability.

How to detect it

To determine whether exploitation already occurred, review application logs, centralized logging, APM traces, API gateway logs, WAF logs, and load balancer access logs for bursts of high-cardinality failed requests followed by retry or circuit-breaker failures. Look for repeated unique request values, unusually high 4xx/5xx responses from the same source or source ranges, sudden increases in retry failures, and application errors referencing Spring Retry cache capacity. Correlate the first appearance of retry cache exceptions with traffic spikes and with downstream service errors. Review JVM/application metrics for sustained increases in exception rates, failed retry counts, circuit-breaker open/failure events, request latency, and error rates. Because exploitation may not leave a file-system artifact, detection is primarily log-, metric-, and traffic-based. If logs contain full stack traces, search for Spring Retry retry-cache exception classes and messages.

• org.springframework.retry.policy.RetryCacheCapacityExceededException
• RetryCacheCapacityExceededException
• Retry cache capacity limit exceeded
• org.springframework.retry.policy.MapRetryContextCache
• MapRetryContextCache
• org.springframework.retry.support.RetryTemplate
• spring-retry-2.0.0.jar
• spring-retry-2.0.1.jar
• spring-retry-2.0.2.jar
• spring-retry-2.0.3.jar
• spring-retry-2.0.4.jar
• spring-retry-2.0.5.jar
• spring-retry-2.0.6.jar
• spring-retry-2.0.7.jar
• spring-retry-2.0.8.jar
• spring-retry-2.0.9.jar
• spring-retry-2.0.10.jar
• spring-retry-2.0.11.jar
• spring-retry-2.0.12.jar
• spring-retry-1.3.0.jar
• spring-retry-1.3.1.jar
• spring-retry-1.3.2.jar
• spring-retry-1.3.3.jar
• spring-retry-1.3.4.jar

What your security team should do

• Inventory applications that include Spring Retry, including transitive dependencies pulled in by Spring-based frameworks or internal shared libraries.
• Prioritize remediation for internet-facing services, APIs handling untrusted input, and systems where retry or circuit-breaker failure could cause cascading outages.
• Upgrade all affected Spring Retry 2.0.x and 1.3.x deployments to vendor-fixed versions outside the vulnerable ranges.
• Add SCA or SBOM policy checks that fail builds when affected Spring Retry versions are introduced.
• Review uses of stateful retry and ensure retry keys cannot be made unbounded or attacker-controlled without validation.
• Add rate limiting and abuse controls to endpoints that can trigger repeated failed retry operations.
• Monitor application logs and reliability metrics for retry cache exhaustion, abnormal unique failure bursts, and circuit-breaker malfunction.
• If suspected exploitation occurred, restart affected application instances after preserving forensic logs, because the cache exhaustion condition can persist for the application lifetime.