Threats Tagged 'cve-2026-41695'

Red Hat OpenShift Dev Spaces provides a cloud developer workspace server and a browser-based IDE built for teams and organizations. Dev Spaces runs in OpenShift and is well-suited for container-based development. The 3.30 release is based on Eclipse Che 7.121 and uses the DevWorkspace engine to provide support for workspaces based on devfile v2.1 and v2.2. Users still using the v1 standard should migrate as soon as possible. https://devfile.io/docs/2.2.0/migrating-to-devfile-v2 Dev Spaces supports OpenShift EUS releases v4.16 and higher. Users are expected to update to supported OpenShift releases in order to continue to get Dev Spaces updates. https://access.redhat.com/support/policy/updates/openshift#crw

`src/main/java/org/springframework/data/mapping/context/PersistentPropertyPathFactory.java:175` · Unbounded Resource Allocation (Algorithmic DoS) ### Impact 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. ### Description `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. ### Exploit scenario 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. ### Preconditions - A downstream component (Spring Data REST, a store-specific `QueryMapper`, or application code) passes externally-supplied strings to `MappingContext.getPersistentPropertyPath(String, ...)` - No upstream rate-limiting or path-string validation ### How to fix 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 `SimplePropertyPath.cache`). Additionally, do not cache `PathResolution.unresolved` results at all (line 204 in `createPersistentPropertyPath`) — re-computing a failed lookup is cheap, and caching negative results for arbitrary attacker strings is what makes this exploitable. ### Adversarial verification **Verdict:** 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** - Line 53: `private final Map<TypeAndPath, PathResolution> propertyPaths = new ConcurrentHashMap<>();` — plain CHM, hard refs, no eviction, no size bound. - Line 175: `propertyPaths.computeIfAbsent(TypeAndPath.of(type, propertyPath), ...)` — every distinct `(type, string)` pair is inserted. - Line 204: `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. - This is the public `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. - No in-repo caller routes HTTP input directly into the `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