CVE-2026-40991 is an XML External Entity (XXE) injection vulnerability in Spring REST Docs when using spring-restdocs-webtestclient or spring-restdocs-restassured to document remote APIs accessed over HTTP. An attacker who compromises or tricks the user into documenting a malicious API can exploit this vulnerability during the execution of documentation-generating tests. The vulnerability affects Spring REST Docs versions 4.0.0, 3.0.0 through 3.0.5, and 2.0.0.RELEASE through 2.0.8.RELEASE. The CVSS score is 5.9 (medium severity). A patch is available for this vulnerability.
`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
Due to incorrect host parsing, applications that rely on UriComponentsBuilder to parse and validate an externally provided URL string may be exposed to a server-side request forgery (SSRF) attack.
Affected versions:
Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18.
In Micrometer, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition.
Affected versions:
micrometer-core 1.16.0 through 1.16.5; 1.15.0 through 1.15.11; 1.14.0 through 1.14.15; 1.13.0 through 1.13.18; 1.9.0 through 1.9.17.
micrometer-jetty11 1.16.0 through 1.16.5; 1.15.0 through 1.15.11; 1.14.0 through 1.14.15; 1.13.0 through 1.13.18.
micrometer-jetty12 1.16.0 through 1.16.5; 1.15.0 through 1.15.11; 1.14.0 through 1.14.15; 1.13.0 through 1.13.18.
Netty's DNS resolver component has a vulnerability in its bailiwick validation for NS records, allowing DNS cache poisoning. An attacker controlling an authoritative name server for a subdomain can inject malicious NS records that are incorrectly accepted as authoritative for parent domains, poisoning the DNS cache. This affects applications using Netty's DNS resolver and can lead to redirection of network traffic and compromise of data integrity.
Netty's DNS resolver component, DnsResolveContext, improperly validates the origin of CNAME records in DNS responses, leading to a DNS cache poisoning vulnerability. This flaw allows attackers to inject malicious DNS data by bypassing bailiwick checks, potentially redirecting network traffic or intercepting sensitive information in applications using Netty for DNS resolution.
A flaw was found in Keycloak. An authenticated administrator with the `manage-clients` role can exploit a Time-of-check to time-of-use (TOCTOU) vulnerability in the name-based admin role checks. This allows the attacker to escalate their privileges to `realm-admin` for all users within the realm, granting them extensive control over the system. The composite role relationship persists even after the attacker's own permissions are revoked and across system reboots.
Apache Shiro's Jakarta EE module improperly uses the HTTP Referer header to determine the redirect target after user login. This insufficient validation of a client-controlled header can allow attackers to influence the redirect destination. The vulnerability affects specific versions of Apache Shiro when using the shiro-jakarta-ee integration module.
Camel-CXF and Camel-Knative Message Header Injection via Missing Inbound Filtering
The CXF and Knative HeaderFilterStrategy implementations (CxfRsHeaderFilterStrategy in camel-cxf-rest, CxfHeaderFilterStrategy in camel-cxf-transport, and KnativeHttpHeaderFilterStrategy in camel-knative-http) only filter outbound Camel-internal headers via setOutFilterStartsWith, while not configuring inbound filtering via setInFilterStartsWith. As a result, an unauthenticated attacker can inject Camel-internal headers (e.g. CamelExecCommandExecutable, CamelFileName) via HTTP requests to CXF-RS or CXF-SOAP endpoints. When a route forwards messages from these endpoints to header-driven components such as camel-exec or camel-file, the injected headers override configured values, enabling remote code execution or arbitrary file writes. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177), the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891), and non-HTTP strategies (CVE-2026-40453).
This issue affects Apache Camel: from 3.18.0 before 4.14.6, from 4.15.0 before 4.18.2.
Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.2. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6.
ArcadeDB is a Multi-Model DBMS. Starting in version 21.10.1 and prior to version 26.4.2, authenticated users and API tokens scoped to a specific database could read, write, and mutate schema on any other database on the same server. Two distinct defects contributed: (1) ServerSecurityUser.getDatabaseUser() returned a DB user with an uninitialized fileAccessMap, which requestAccessOnFile treated as allow-all; (2) ArcadeDBServer.createDatabase() omitted factory.setSecurity(...) so any database created via POST /api/v1/server {"command":"create database X"} had its entire record-level authorization system silently disabled. In combination, record-level and database-level authorization could be bypassed by any authenticated principal. This vulnerability is fixed in 26.4.2.
A critical authentication bypass vulnerability exists in the Unity Catalog server's token exchange endpoint. The endpoint dynamically fetches the JWKS endpoint based on the issuer (iss) claim in incoming JWTs without verifying that the issuer is a trusted identity provider. This allows an attacker to create a malicious JWT signed by their own key, impersonate any user, and gain full access to that user's resources. The vulnerability also involves missing validation of the audience (aud) claim, enabling tokens intended for other services to be accepted. A fix is available in version 0.4.1.
A vulnerability in Netty's HTTP/3 codec (netty-codec-http3) allows an attacker to cause unbounded memory allocation during QPACK header decoding. Specifically, the decoder may allocate a large byte array based on a length value from the wire without verifying that the data is actually present, enabling a denial-of-service condition due to excessive memory consumption.
A regression in OpenSearch versions 2.18.0 through before 2.19.4.0 and 3.0.0 through before 3.3.0.0 caused the TLS certificate hostname verification setting to be ineffective. When enabled, OpenSearch did not verify that the hostname in a connecting node's TLS certificate matched the connection hostname, allowing nodes with valid certificates but incorrect hostname SANs to join the cluster. This issue affects only the hostname verification step, not the overall certificate validation. The vulnerability is fixed in versions 2.19.4.0 and 3.3.0.0.
A vulnerability in the OpenSearch Security plugin's document-level security (DLS) allows authenticated users to bypass DLS restrictions on documents linked by has_parent or has_child join relations. This affects clusters using both DLS and the join field type on the same index. The issue is fixed in OpenSearch versions 2.19.4 and 3.2.0.
A vulnerability in the OpenSearch Security plugin allows improper authorization checks during index rollover requests. Specifically, when a rollover request specifies an explicit target index name, the plugin fails to properly verify access permissions for the target index. This flaw enables users with rollover permissions on a source index to create new indices with unauthorized names. The issue affects OpenSearch versions prior to 2.19.4.0 and 3.2.0.0 and has a low severity rating. Fixed versions are available.
A vulnerability in the OpenSearch REST layer allows bypassing authorization checks via malformed HTTP requests, potentially granting unauthorized read access to certain API endpoints. The default OpenSearch distribution is not affected due to transport-level authorization enforcement. Custom plugins that register REST actions without corresponding transport actions may be vulnerable. The issue is fixed in OpenSearch version 2.19.0.
Apache Wicket versions from 8.0.0 through 8.17.0, 9.0.0 through 9.22.0, and 10.0.0 through 10.8.0 contain a vulnerability that exposes sensitive information to unauthorized actors. This issue is resolved in version 10.9.0. The vulnerability has a high severity with a CVSS score of 7.5, indicating network exploitable exposure with no privileges or user interaction required.
Apache Wicket versions 8.0.0 through 8.17.0, 9.0.0 through 9.22.0, and 10.0.0 through 10.8.0 contain a path traversal vulnerability in FolderUploadsFileManager. The vulnerability allows unauthenticated attackers to write files outside the intended upload directory or read arbitrary files on the server by exploiting insufficient validation of the uploadFieldId and clientFileName parameters. This issue is fixed in version 10.9.0.
Apache Wicket versions from 8.0.0 through 8.17.0, 9.0.0 through 9.22.0, and 10.0.0 through 10.8.0 are affected by a session fixation vulnerability (CVE-2026-40010). The issue arises from missing invocation of the Servlet HTTP request method changeSessionId after session binding, which can allow an attacker to fixate a user's session ID. This vulnerability is fixed in version 10.9.0.
Apache Wicket versions from 8.0.0 through 8.17.0, 9.0.0 through 9.22.0, and 10.0.0 through 10.8.0 contain a Cross-site Scripting (XSS) vulnerability. This flaw allows improper neutralization of input during web page generation, potentially enabling attackers to inject malicious scripts. The issue is fixed in version 10.9.0, which users are advised to upgrade to.