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

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

Which versions of Spring Data Commons are affected by CVE-2026-41716?

Spring Data Commons versions 2.7.0 through 4.0.5 contain a memory exhaustion vulnerability allowing unauthenticated remote attackers to crash applications by sending crafted requests that fill JVM…. A patch is available.

How to fix or mitigate CVE-2026-41716?

Within 24 hours: Complete inventory of all applications using Spring Data Commons versions 2.7.0-4.0.5 and classify by criticality. Within 7 days: Deploy rate limiting on endpoints accepting dynamic property inputs, enable JVM heap monitoring with alerts at 80% utilization threshold, and validate or truncate property-name inputs to reasonable length limits. Within 30 days: Establish upgrade readiness plan for patched versions when available; implement request queue limits and service isolation strategies to contain blast radius of individual application failures.

Spring Data Commons CVE-2026-41716

EUVD-2026-35899 HIGH

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

2026-06-10 security@vmware.com

GHSA-9fw2-h3hf-293r

Denial Of Service Java Spring Data Commons

7.5

CVSS 3.1 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

7.5 HIGH

AV:N/AC:L/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:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Patch available

Jun 10, 2026 - 02:01 EUVD

Analysis Generated

Jun 10, 2026 - 00:33 vuln.today

DescriptionCVE.org

Spring Data's internal property-lookup cache accepts and permanently retains attacker-supplied strings as cache keys, allowing heap exhaustion through repeated requests.

Affected versions: Spring Data Commons 2.7.0 through 2.7.19; 3.3.0 through 3.3.16; 3.4.0 through 3.4.14; 3.5.0 through 3.5.11; 4.0.0 through 4.0.5.

AnalysisAI

Denial-of-service in Spring Data Commons (versions 2.7.0-4.0.5) allows remote unauthenticated attackers to exhaust JVM heap memory by repeatedly submitting unique property-name strings that are permanently retained in an internal property-lookup cache. The flaw maps to CWE-770 (Allocation of Resources Without Limits or Throttling) and carries a CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) reflecting purely availability impact. No public exploit identified at time of analysis and the issue is not currently listed in CISA KEV.

Technical ContextAI

Spring Data Commons is the shared infrastructure module underlying the Spring Data family (JPA, MongoDB, Redis, etc.) widely embedded in Spring Boot applications. It maintains an internal cache that maps property-name strings to resolved PropertyPath / TypeInformation objects to avoid repeating expensive reflective lookups on each request. Because the cache key is derived directly from caller-supplied property names (commonly reachable through query parameters, sort/filter expressions, projections, or PagingAndSortingRepository's sort= parameter) and the cache has no eviction or size bound, every distinct attacker-supplied string is added and never released. This is a textbook CWE-770 resource-allocation issue: the cache grows unbounded with attacker-controlled keys until the JVM heap is exhausted and the application OOMs.

RemediationAI

Patch availability is referenced via the Spring advisory at https://spring.io/security/cve-2026-41716 but exact fixed versions were not provided in the input - treat this as 'patch available per vendor advisory' and consult that page for the upgrade target within each branch (2.7.x, 3.3.x, 3.4.x, 3.5.x, 4.0.x), then bump the spring-data-commons dependency (or the Spring Boot BOM that pins it) accordingly and rebuild. For deployments that cannot upgrade immediately, the most effective compensating control is to constrain the attack surface: validate or allow-list the property names accepted on sort/filter/projection parameters (e.g., reject any sort= value not in a known field set) before they reach Spring Data, which prevents unbounded unique strings from reaching the cache at the cost of a small amount of per-endpoint code. Where Spring Data REST is exposed publicly without need, disable it or move it behind authentication; additionally, set conservative JVM heap limits with -XX:+ExitOnOutOfMemoryError plus a process supervisor so an exhaustion attack causes a fast restart rather than a long degraded state - this is a containment, not a fix.