CVE-2026-40989

What it actually does

The flaw is an uncontrolled recursion condition in the Spring Cloud Function routing layer. When a vulnerable application processes specially crafted or cyclic routing input, request handling can recurse until JVM memory is exhausted, causing `OutOfMemoryError`, severe garbage collection pressure, thread starvation, or process termination. The primary impact is availability loss; confidentiality is not directly affected. A limited integrity impact is possible where malformed routing behavior disrupts normal request processing or causes requests to be handled incorrectly before failure.

Why it matters to the business

Applications built on affected Spring Cloud Function versions can be crashed or made unresponsive by triggering the routing flaw, resulting in service outages, failed transactions, degraded APIs, autoscaling instability, and operational incident response costs. This is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score with no 30-day movement, but internet-facing or high-traffic function endpoints should still be prioritized because a denial-of-service condition can be triggered through normal request-processing paths once the attacker can influence routing input.

How an attack unfolds

An attacker first identifies an application using a vulnerable Spring Cloud Function version and locates an invocation path where function routing is enabled or where routing metadata can be influenced. The attacker then submits a request or message with routing information that causes the routing layer to resolve recursively instead of terminating normally. As the application attempts to route the request, recursive calls consume heap memory and CPU through repeated object allocation and garbage collection. Eventually the JVM reports an out-of-memory condition, the container or process may be killed, and the service becomes unavailable until restarted or rescheduled. Repeated triggering can keep the application in a crash loop or degrade the broader service tier.

How to fix it

Upgrade Spring Cloud Function to a fixed release for the active branch in use: 3.2.x should be upgraded to 3.2.16 or later; 4.1.x to 4.1.10 or later; 4.2.x to 4.2.6 or later; 4.3.x to 4.3.3 or later; and 5.0.x to 5.0.2 or later. Older unsupported versions should be upgraded to a supported fixed branch. Rebuild and redeploy all applications that package the vulnerable dependency directly or transitively. If immediate upgrade is not possible, reduce exposure by restricting access to function invocation endpoints, validating and allow-listing routing headers and routing expressions, disabling dynamic routing where not required, applying request size and rate limits, and configuring container memory limits and restart policies to contain impact. These mitigations reduce risk but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm dependency resolution rather than only checking source manifests, because Spring Cloud Function may be brought in transitively. For Maven, inspect `mvn dependency:tree` and verify `org.springframework.cloud:spring-cloud-function-*` artifacts resolve to a fixed version. For Gradle, inspect `gradle dependencies` or dependency lockfiles for the same artifacts. Validate running artifacts by checking SBOMs, container image dependency reports, application startup dependency logs, or packaged JAR contents. After upgrading, exercise normal function-routing paths and confirm they complete without recursive failures or JVM memory exhaustion. For exposure validation, identify endpoints or message consumers that accept user-controllable routing metadata such as `spring.cloud.function.definition` or routing-expression inputs, then verify they are authenticated, constrained, or removed if unnecessary.

Typical attack path

1. Identify an application or service built with Spring Cloud Function and exposeable function-routing behavior.
2. Determine whether request headers, message headers, parameters, or broker-delivered metadata can influence function routing.
3. Send crafted routing input that causes recursive routing resolution in the vulnerable routing layer.
4. Force repeated recursion until the JVM heap is exhausted or garbage collection stalls request handling.
5. Cause the application instance to become unresponsive, terminate, restart, or enter a crash loop.
6. Repeat requests against restarted instances or multiple replicas to sustain denial of service.

How to detect it

Review application logs, JVM logs, container runtime events, orchestrator events, API gateway logs, load balancer logs, and message broker consumer logs for evidence of routing-triggered memory exhaustion. Useful signs include sudden `OutOfMemoryError` events, excessive garbage collection, process exits, container `OOMKilled` events, exit code 137, repeated restarts, elevated 5xx responses, and spikes of requests carrying Spring Cloud Function routing headers or routing-expression metadata. Correlate crashes with inbound HTTP requests or broker messages containing routing fields such as `spring.cloud.function.definition` or `spring.cloud.function.routing-expression`. In Kubernetes or similar platforms, examine pod events, previous container logs, restart counts, and node OOM events. Because there are no public CVE-specific exploit strings, detection should focus on the combination of user-controllable routing input immediately followed by JVM memory exhaustion or application restart.

• java.lang.OutOfMemoryError
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• java.lang.OutOfMemoryError: Metaspace
• java.lang.StackOverflowError
• GC overhead limit exceeded
• OOMKilled
• Exit Code: 137
• ExitCode: 137
• Killed process
• Container killed due to memory usage
• org.springframework.cloud.function.context.config.RoutingFunction
• spring.cloud.function.definition
• spring.cloud.function.routing-expression
• spring.cloud.function.routingExpression

What your security team should do

• Inventory applications and container images using Spring Cloud Function, including transitive dependencies and older unsupported branches.
• Prioritize upgrade of internet-facing, partner-facing, message-driven, or high-availability services that expose function routing behavior.
• Upgrade to the fixed version for the deployed branch: 3.2.16+, 4.1.10+, 4.2.6+, 4.3.3+, or 5.0.2+.
• Add allow-list validation for routing metadata and block untrusted dynamic routing expressions where business logic does not require them.
• Apply rate limits, request limits, and authentication controls to function invocation endpoints and message ingress paths.
• Monitor JVM memory, garbage collection, container restarts, OOM kills, and sudden spikes in 5xx responses for affected services.
• Search historical logs for out-of-memory crashes and routing-related errors around suspicious request bursts.
• Ensure orchestration platforms have sane memory limits and restart policies, while recognizing that restarts do not remediate the vulnerable code path.