| Package | Affected versions | Patched versions |
|---|---|---|
| org.springframework.data:spring-data-commons | ≥ 3.4.0, ≤ 3.4.13≥ 3.5.0, < 3.5.12≥ 4.0.0, < 4.0.6 | 3.5.124.0.6 |
| spring data commons | ≥ 3.4.0, < 3.4.15≥ 3.5.0, < 3.5.11.1≥ 4.0.0, < 4.0.5.1 | 3.4.153.5.11.14.0.5.1 |
src/main/java/org/springframework/data/mapping/context/PersistentPropertyPathFactory.java:175 · Unbounded Resource Allocation (Algorithmic DoS)
When a consuming module routes user-supplied dot-paths (sort parameters, projection paths, PATCH paths) through MappingContext.getPersistentPropertyPath(String, Class), each distinct string — including invalid ones — is cached forever. A remote attacker can send millions of requests with unique ?sort=aaaa<n> values and grow the heap until the service OOMs.
PersistentPropertyPathFactory.propertyPaths (line 53) is a ConcurrentHashMap<TypeAndPath, PathResolution> populated by getPotentiallyCachedPath() (line 174-177) via computeIfAbsent. The key is (TypeInformation, rawPathString). Crucially, unresolvable paths are also cached (as PathResolution.unresolved, line 204) so that the same InvalidPersistentPropertyPath can be re-thrown — meaning every distinct garbage string an attacker sends creates a permanent entry. There is no eviction. This is reachable from AbstractMappingContext.getPersistentPropertyPath(String, Class) (AbstractMappingContext.java:345), which Spring Data REST and several store query mappers call with HTTP-request-derived sort/filter property names.
By contrast, the sibling SimplePropertyPath.cache was already hardened to use ConcurrentReferenceHashMap (soft refs); this cache was not given the same treatment.
Against a Spring Data REST endpoint, an attacker scripts GET /things?sort=<random-40-char-string> in a loop. Each request fails fast with InvalidPersistentPropertyPath, but each distinct random string leaves behind a TypeAndPath key, a PathResolution object holding the split segments list, and the source string in the map. After ~10M requests the JVM OOMs.
QueryMapper, or application code) passes externally-supplied strings to MappingContext.getPersistentPropertyPath(String, ...)A cache whose key can be derived from external input must be bounded. Replace propertyPaths (line 53) with a ConcurrentLruCache<TypeAndPath, PathResolution> of fixed capacity, or ConcurrentReferenceHashMap (matching the sibling ). Additionally, do not cache results at all (line 204 in ) — re-computing a failed lookup is cheap, and caching negative results for arbitrary attacker strings is what makes this exploitable.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeSimplePropertyPath.cachePathResolution.unresolvedcreatePersistentPropertyPathVerdict: TRUE_POSITIVE (confidence: 7/10) — unbounded hard-ref ConcurrentHashMap keyed by raw path string, caches unresolved entries (line 204), reachable via public MappingContext.getPersistentPropertyPath(String, ...); sibling PropertyPath cache was already converted to soft-refs but this one was missed. -3 confidence because the HTTP-input wiring lives in downstream modules (Spring Data REST / store mappers), not verifiable in this repo.
Code at the line — CONFIRMED
private final Map<TypeAndPath, PathResolution> propertyPaths = new ConcurrentHashMap<>(); — plain CHM, hard refs, no eviction, no size bound.propertyPaths.computeIfAbsent(TypeAndPath.of(type, propertyPath), ...) — every distinct (type, string) pair is inserted.return PathResolution.unresolved(parts, segment, type, currentPath); — returned from inside computeIfAbsent's mapping function, so unresolvable paths are cached. The PathResolution retains the full attacker string (source = StringUtils.collectionToDelimitedString(parts, "."), line 452).Callers within spring-data-commons
AbstractMappingContext.getPersistentPropertyPath(String, Class<?>) (line 345) and (String, TypeInformation<?>) (line 350) → persistentPropertyPathFactory.from(type, propertyPath) → straight into the unbounded cache. No validation, no PropertyPath.from gate.MappingContext interface (MappingContext.java:174,186), documented to throw InvalidPersistentPropertyPath on bad input — i.e., the contract explicitly anticipates being called with possibly-invalid strings.String overload. The Sort.Order.property → getPersistentPropertyPath(String, ...) bridge lives in store modules (Spring Data MongoDB QueryMapper, Spring Data REST sort translator). That wiring is out-of-repo as the finding states.Protections — NONE on this cache
Contrast: SimplePropertyPath.java:52 (the PropertyPath.from cache) uses ConcurrentReferenceHashMap (soft refs, GC-evictable). Spring already hardened the sibling cache against exactly this pattern. PersistentPropertyPathFactory.propertyPaths was not given the same treatment.
Stress-test
Is this exclusion #3 (intended design)? The PathResolution javadoc (line 426-430) says caching unresolved paths is deliberate — to make repeated lookups of the same bad path cheap. But unbounded hard-ref caching of arbitrary attacker-chosen keys is not the intent; the sibling fix proves Spring considers this a bug class.