What is the CVSS score of CVE-2026-41710?

CVE-2026-41710 has a CVSS 3.1 base score of 5.9 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-41710?

Yes, a patch is available for CVE-2026-41710. Update the affected software to the latest version immediately.

Spring Retry CVE-2026-41710

EUVD-2026-35321 MEDIUM

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-06-09 vmware

GHSA-2827-2mxx-j8pv

Denial Of Service Java Spring Retry

5.9

CVSS 3.1 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

5.9 MEDIUM

AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (vmware) · only source for this CVE.

CVSS VectorVendor: vmware

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Patch available

Jun 09, 2026 - 06:01 EUVD

Analysis Generated

Jun 09, 2026 - 05:28 vuln.today

DescriptionCVE.org

An attacker can craft a large number of unique requests that trigger a failure, exhausting the capacity of the application-wide stateful retry cache. Once the cache is full, it permanently rejects any further updates, causing all later stateful retries and circuit breakers in the application to fail.

Affected versions: Spring Retry 2.0.0 through 2.0.12; 1.3.0 through 1.3.4.

AnalysisAI

Stateful retry cache exhaustion in Spring Retry 1.3.0-1.3.4 and 2.0.0-2.0.12 allows an unauthenticated remote attacker to permanently disable all retry and circuit breaker logic application-wide by flooding the service with uniquely crafted failure-triggering requests until the bounded cache is saturated. Once exhausted, the cache enters a terminal rejection state that persists until the application is restarted - making this a durable, high-impact denial-of-service condition against Java services relying on Spring Retry for resilience. No public exploit has been identified at time of analysis, and CISA KEV listing is absent, but the network-accessible unauthenticated attack surface makes this relevant to any internet-facing Spring application using stateful retry patterns.

Technical ContextAI

Spring Retry is a VMware-maintained Java library providing declarative retry and stateful circuit breaker functionality for Spring-based applications, typically consumed via @Retryable annotations or programmatic RetryTemplate configurations. The vulnerability maps to CWE-770 (Allocation of Resources Without Limits or Throttling): the library maintains a single application-wide, bounded cache for tracking stateful retry state across calls. This cache lacks an eviction or overflow policy sufficient to prevent permanent saturation - once all slots are consumed, the cache does not discard stale entries but instead permanently rejects any further insertions. This collapses the entire retry and circuit breaker subsystem for the lifetime of the JVM process. The CPE string cpe:2.3:a:spring:spring_retry:*:*:*:*:*:*:*:* confirms the vulnerability exists across the spring-retry artifact broadly within the stated version bands, independent of deployment environment.

RemediationAI

The primary fix is to upgrade Spring Retry to the next release beyond the affected ranges - beyond 2.0.12 for the 2.x branch or beyond 1.3.4 for the 1.3.x branch - once the vendor releases the patched version confirmed at https://spring.io/security/cve-2026-41710. Exact patched version numbers are not confirmed from available input data and must be verified directly from the advisory before upgrading. As a compensating control while patching, implement rate limiting at the API gateway or load balancer layer to constrain the volume of unique failure-triggering requests any single client or IP range can generate, which raises the cost of exhausting the cache; note this does not eliminate the vulnerability and may not stop a distributed attacker. Configuring automated application restart policies (e.g., Kubernetes liveness probes tied to health endpoint degradation) reduces the persistence of the saturated-cache state, limiting the outage window at the cost of brief service interruption on restart. Temporarily switching stateful retry configurations to stateless retry removes the vulnerable cache population path entirely but also eliminates circuit breaker protections, which may increase failure propagation to downstream dependencies.