Spring Cloud Function SpEL injection RCE (CVE-2022-22963)

In March 2022, while the security world was consumed by the chaos of Spring4Shell (CVE-2022-22965), a second and arguably more directly exploitable vulnerability was quietly patched in a sibling project: Spring Cloud Function. CVE-2022-22963 is a Spring Expression Language (SpEL) injection vulnerability that allows an unauthenticated attacker to achieve remote code execution against any application exposing Spring Cloud Function's routing functionality over HTTP. A single crafted header is enough to run arbitrary commands on the underlying host — no authentication, no user interaction, no exploit chain required. Because it landed in the same news cycle as Spring4Shell, CVE-2022-22963 was frequently overlooked or conflated with its more famous cousin, even though it is a distinct root cause, a distinct fix, and a distinct set of affected artifacts. For any organization running microservices built on Spring Cloud Function — a common choice for serverless and event-driven Java workloads on AWS Lambda, Azure Functions, and Kubernetes-based FaaS platforms — this vulnerability deserves its own dedicated remediation pass.

What Went Wrong

Spring Cloud Function provides a routing feature that lets a single deployed function dispatch incoming requests to one of several underlying functions based on a routing expression. That expression can be supplied by the caller via the spring.cloud.function.routing-expression HTTP header or as a Spring property, and it is evaluated as a SpEL expression by the framework before the request is routed.

The problem is that SpEL is a full expression language, not a narrow routing DSL. It supports type resolution, static method invocation, and constructor calls. An attacker who controls the routing expression can use SpEL's T() operator to reference arbitrary classes on the classpath, chain constructor and method calls, and ultimately invoke java.lang.Runtime.exec() or construct a ProcessBuilder — all from an unauthenticated HTTP header. Because Spring Cloud Function evaluates this expression eagerly as part of normal request processing, no special endpoint or feature flag needs to be enabled; any deployment that accepts HTTP requests through the function-routing path is exposed by default.

This is the same underlying vulnerability class — SpEL injection — that has bitten the Spring ecosystem before, but the attack surface here is unusually clean: a single header, no multi-step exploit chain, and immediate code execution in the context of the JVM process. Public proof-of-concept payloads surfaced within hours of disclosure, and mass internet scanning for vulnerable Spring Cloud Function endpoints began almost immediately.

Affected Versions and Components

• Component: spring-cloud-function-context (and by extension, applications built on spring-cloud-function-web or spring-cloud-function-adapter-aws that expose the routing HTTP path)
• Affected versions: Spring Cloud Function 3.1.6 and earlier in the 3.1.x line, 3.2.2 and earlier in the 3.2.x line, and older unsupported release trains
• Fixed versions: 3.1.7 and 3.2.3 (and all subsequent releases)
• Trigger: any HTTP request that sets the spring.cloud.function.routing-expression header (or otherwise supplies a routing expression evaluated by the framework's RoutingFunction logic)

It's worth stressing that this is a different codebase and a different fix than Spring4Shell. Patching core Spring Framework (spring-webmvc/spring-webflux) to remediate CVE-2022-22965 does nothing to close this hole — teams need to independently locate and upgrade the spring-cloud-function-context dependency wherever it appears in their dependency tree, including transitively through starter dependencies or serverless adapter modules.

Severity: CVSS and EPSS Context

NVD scores CVE-2022-22963 as Critical, CVSS v3.1 base score 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) — network-exploitable, low attack complexity, no privileges or user interaction required, and full impact to confidentiality, integrity, and availability. That's the ceiling of the CVSS scale for a reason: there is effectively no precondition an attacker needs beyond network reachability to the vulnerable endpoint.

EPSS (Exploit Prediction Scoring System) data for this CVE has consistently sat in the upper percentile of all scored vulnerabilities, reflecting the fact that working exploit code was public almost immediately and that Spring Cloud Function deployments were actively probed at internet scale in the weeks following disclosure. Whatever the exact EPSS snapshot on a given day, the practical signal is the same: this is a vulnerability that gets exploited automatically, not one that requires a targeted, motivated adversary. We'd encourage security teams to treat "not yet in CISA's Known Exploited Vulnerabilities catalog" as an accident of listing criteria rather than a reason to deprioritize — the CVSS score, the trivial exploitation path, and the historical scanning volume all argue for urgent patching independent of KEV status.

Timeline

• ~March 2022: Spring Cloud Function's routing-expression handling identified as vulnerable to SpEL injection and reported to VMware Tanzu (the Spring Cloud Function maintainers).
• March 29, 2022: VMware published the security advisory alongside patched releases 3.1.7 and 3.2.3, and CVE-2022-22963 was assigned.
• Late March 2022: Because the disclosure landed in the same window as Spring4Shell (CVE-2022-22965), public attention and remediation effort was split — and in many cases, teams patched core Spring Framework and mistakenly assumed Spring Cloud Function deployments were covered too.
• Days after disclosure: Public proof-of-concept exploits circulated widely, and mass scanning for exposed /functionRouter and routing-capable endpoints was observed across the internet, including automated attempts to drop web shells and cryptomining payloads on compromised hosts.
• Ongoing: Because Spring Cloud Function is embedded in serverless adapters and often deployed as a dependency rather than a standalone service, unpatched instances have continued to surface in dependency and SBOM audits years after the original disclosure — a pattern typical of libraries pulled in transitively rather than upgraded directly.

Remediation Steps

1. Upgrade first. Update spring-cloud-function-context (and any starter or adapter that pulls it in — spring-cloud-function-web, spring-cloud-function-adapter-aws, etc.) to at least version 3.1.7 or 3.2.3, or to any current supported release. Check transitive dependencies specifically; many teams found this library several layers deep in a build tool's dependency tree, unmanaged by an explicit version pin.
2. Audit every build artifact, not just services you remember. Spring Cloud Function is popular in serverless/FaaS contexts precisely because it's easy to bundle into a Lambda or Azure Function package. Search build manifests, container images, and deployed artifacts — not just active source repos — for the vulnerable dependency, since serverless packages are frequently built once and rarely revisited.
3. If you cannot patch immediately, block the attack vector at the edge. Configure your WAF or reverse proxy to strip or reject requests containing a spring.cloud.function.routing-expression header that includes SpEL syntax markers such as T(, new java.lang., ProcessBuilder, Runtime, or exec(. This is a compensating control, not a fix — treat it as a bridge to patching, not a replacement for it.
4. Disable or restrict the routing feature if it's unused. If your deployment doesn't rely on header-based function routing, disable that code path or ensure it isn't reachable from untrusted networks.
5. Segment and restrict network exposure. Ensure Spring Cloud Function-based services aren't unnecessarily reachable from the public internet, and apply least-privilege network policies between services.
6. Hunt for indicators of prior compromise. Review access logs for the routing-expression header pattern, check for unexpected outbound connections or spawned child processes from JVM-hosted services during the disclosure window, and rotate credentials and secrets on any host where exploitation is suspected.
7. Re-verify after patching. Confirm the fixed version is actually what's running in production — not just what's declared in a manifest — since build caching and layered container images can leave stale, vulnerable jars in place even after a source-level bump.

How Safeguard Helps

Vulnerabilities like CVE-2022-22963 are exactly where alert fatigue does the most damage: a critical, trivially exploitable CVE gets lost in the noise of a simultaneous, higher-profile disclosure, and teams patch the wrong library while the real exposure sits untouched. Safeguard's reachability analysis cuts through that noise by confirming whether the vulnerable spring-cloud-function-context routing path is actually present and invocable in your deployed code, so your team can prioritize the services genuinely exposed to unauthenticated RCE instead of triaging every dependency hit equally. Our automated SBOM generation and ingest pipeline surfaces this library even when it's buried several layers deep in a serverless build artifact or container image, closing the exact blind spot that let CVE-2022-22963 linger in production long after patches were available. Griffin AI, Safeguard's analysis engine, correlates the CVSS severity, EPSS exploitation likelihood, and your actual dependency graph to generate a prioritized, risk-ranked remediation queue rather than a flat CVE list. And once a fix is identified, Safeguard can open an auto-fix pull request that bumps the affected dependency to a patched release across every affected repository, turning what historically took security teams days of manual dependency hunting into a same-day remediation.