CVE-2026-40990

What it actually does

CVE-2026-40990 is a denial-of-service flaw in Spring Cloud Function where the Function Registry can be driven to accept an unbounded number of function registrations. Repeated function additions can exhaust JVM heap memory, causing OutOfMemoryError conditions, degraded application behavior, process termination, or container restarts. The primary impact is availability loss; limited integrity impact may occur if unexpected function registration changes application behavior before the service fails.

Why it matters to the business

Applications using affected Spring Cloud Function versions may become unstable or unavailable if an attacker or low-privileged user can trigger repeated function registration. This can interrupt APIs, event-processing workloads, serverless-style functions, message consumers, and dependent business workflows. The CVSS score is moderate and EPSS is currently low with no known KEV listing or public exploit maturity, but the operational impact can still be significant for internet-facing or high-throughput services where memory exhaustion causes cascading outages.

How an attack unfolds

An attacker first needs a path that can influence Spring Cloud Function registration behavior, such as authenticated access, a misconfigured administrative or integration interface, exposed development functionality, or another application feature that causes functions to be added to the Function Registry. The attacker repeatedly submits inputs or actions that cause new function entries to be registered without a practical upper bound. As the registry grows, JVM heap usage increases until garbage collection cannot reclaim enough memory. The application then experiences severe latency, repeated garbage-collection pauses, OutOfMemoryError exceptions, failed requests, process crashes, or container restarts. In orchestrated environments, this may lead to restart loops and service instability until the malicious traffic or triggering condition is removed and the software is upgraded.

How to fix it

Upgrade Spring Cloud Function to a fixed version for the deployed release line: upgrade 3.2.x 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 release. If immediate upgrade is not possible, restrict access to any administrative, development, actuator, integration, or custom endpoints that can influence function registration; require strong authentication and authorization; disable unnecessary dynamic registration features; apply rate limits; and set JVM/container memory limits with monitoring so failures are contained rather than cascading. These mitigations reduce exposure but should not be treated as a substitute for applying the fixed Spring Cloud Function version.

How to confirm the fix worked

Confirm the deployed dependency tree no longer includes vulnerable Spring Cloud Function versions. For Maven, review `mvn dependency:tree` output for `org.springframework.cloud:spring-cloud-function-*`; for Gradle, review `gradle dependencies` or dependency lockfiles. Validate that runtime artifacts, container images, and SBOMs show Spring Cloud Function 3.2.16+, 4.1.10+, 4.2.6+, 4.3.3+, or 5.0.2+ as applicable. After upgrading, run application regression tests that exercise function discovery and registration paths, then monitor heap usage under representative load to confirm memory does not grow unbounded. Also verify that any administrative or integration paths capable of registering functions are not anonymously accessible and are protected by authorization and rate limiting.

Typical attack path

1. Identify an application or service using an affected Spring Cloud Function version.
2. Find an exposed or reachable feature that can cause dynamic function registration or interact with the Function Registry.
3. Authenticate or induce required user interaction if the vulnerable path requires it.
4. Repeatedly trigger creation or registration of additional functions.
5. Drive JVM memory consumption upward until heap exhaustion occurs.
6. Cause service degradation, request failures, application crashes, or container restart loops.

How to detect it

To determine whether this was already exploited, review application logs, JVM logs, container logs, orchestrator events, APM telemetry, and ingress/API gateway logs for periods of unexplained heap growth or crashes. Look for `java.lang.OutOfMemoryError`, excessive full garbage collection, sudden increases in registered function counts, repeated application restarts, and request bursts to any endpoint or feature associated with function lookup, function composition, dynamic registration, actuator access, integration management, or custom administrative operations. Correlate memory-exhaustion timestamps with source IPs, authenticated principals, session identifiers, request paths, user agents, and message broker events. In Kubernetes or container platforms, check pod restart counts, OOMKilled events, liveness probe failures, and node memory pressure around the same time. Since no public exploit pattern or named threat actor is currently known for this CVE, detection should focus on behavioral evidence of registry growth and JVM memory exhaustion rather than a single definitive exploit signature.

• java.lang.OutOfMemoryError
• java.lang.OutOfMemoryError: Java heap space
• OutOfMemoryError: GC overhead limit exceeded
• org.springframework.cloud.function
• FunctionRegistry
• FunctionCatalog
• spring-cloud-function
• OOMKilled
• CrashLoopBackOff
• Full GC
• GC overhead limit exceeded
• Application run failed
• java.lang.OutOfMemoryError: Metaspace

What your security team should do

• Inventory applications and container images that include Spring Cloud Function, especially services exposing function, integration, actuator, or administrative capabilities.
• Prioritize upgrades for internet-facing services, message-processing systems, serverless workloads, and applications with high availability requirements.
• Upgrade to the fixed version for the active release line: 3.2.16+, 4.1.10+, 4.2.6+, 4.3.3+, or 5.0.2+.
• For unsupported Spring Cloud Function versions, plan migration to a supported fixed release rather than attempting long-term compensating controls.
• Restrict and monitor access to endpoints or features that can influence function registration.
• Add alerts for rapid JVM heap growth, repeated full garbage collections, OutOfMemoryError events, process crashes, and container restart loops.
• Review application logs for historical memory-exhaustion events correlated with unusual request bursts or authenticated user activity.
• Because EPSS is currently low and the CVE is not in CISA KEV, schedule according to exposure and service criticality, but treat exposed dynamic-registration paths as urgent.