CVE-2024-38808

What it actually does

The flaw is an availability issue in Spring Framework 5.3.0 through 5.3.38 and older unsupported releases when an application evaluates Spring Expression Language expressions supplied by an untrusted user. A specially crafted SpEL expression can trigger excessive processing or resource consumption during parsing or evaluation, causing slow responses, thread exhaustion, elevated CPU usage, or partial service degradation. The issue does not provide direct confidentiality or integrity impact and is only exploitable in applications that expose user-controllable SpEL evaluation paths.

Why it matters to the business

Successful exploitation can make affected Spring-based services unreliable or temporarily unavailable, disrupting business workflows that depend on those applications. The public risk signal is currently low: it is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no widely reported mature exploit; however, internet-facing or high-traffic applications that accept expression-like input should still be prioritized because even a low-complexity denial-of-service condition can affect service availability. Organizations should also verify package inventory carefully because the provided affected product data includes Spring Framework as the primary relevant component and a legacy Ubuntu qemu package entry that should be remediated only where it actually exists and is applicable.

How an attack unfolds

An attacker first identifies an application feature, API, form, rule engine, search/filter capability, template field, configuration interface, or integration point that accepts user-provided input and passes it to a Spring SpEL parser or evaluator. The attacker then submits a crafted expression designed to consume excessive resources during expression parsing or evaluation. If the vulnerable Spring Framework version is present and the application evaluates the expression without strict validation, sandboxing, length limits, or timeouts, application worker threads or CPU resources can be tied up. Repeated requests can amplify the effect, resulting in latency, request failures, health-check failures, or partial application outage. No authentication may be required if the vulnerable expression-evaluation feature is publicly reachable, but some deployments may require access to a user-driven workflow or administrative/configuration feature.

How to fix it

Upgrade affected Spring Framework 5.3.x deployments to a fixed release containing the vendor fix, such as Spring Framework 5.3.39 or later where compatible, or migrate to a currently supported Spring Framework line. The specific upstream fix is identified as spring-projects/spring-framework commit f1b128b88d734670b4e1842e9ecf41f5252c778d. Remove or redesign application features that evaluate untrusted SpEL input whenever possible. If SpEL evaluation is required, restrict it to trusted users and trusted expression sources, enforce strict allowlists, cap expression length and complexity, apply request rate limits, set execution timeouts, and isolate expression evaluation from critical request-handling paths. For systems where Ubuntu 14.04 qemu package exposure is separately confirmed, update qemu to 2.0.0+dfsg-2ubuntu1.17 or later, but do not treat qemu remediation as a substitute for fixing Spring Framework exposure.

How to confirm the fix worked

Confirm dependency versions through build manifests, lockfiles, SBOMs, artifact metadata, and runtime classpath inspection. Look specifically for org.springframework:spring-expression and related Spring Framework components in versions 5.3.0 through 5.3.38 or older unsupported versions. Review code for use of SpelExpressionParser, ExpressionParser, StandardEvaluationContext, SimpleEvaluationContext, @Value-driven dynamic inputs, rule/configuration engines, or template/custom filter features that evaluate user-controllable strings. After upgrading, verify that the deployed artifact contains the fixed Spring Framework version or the upstream fix commit. Perform safe negative testing in a non-production environment using malformed and high-complexity expression inputs to confirm that requests are rejected, bounded, or fail quickly without sustained CPU/thread exhaustion. Validate compensating controls by confirming request size limits, rate limits, authentication requirements, and application-level timeouts are active.

Typical attack path

1. Identify a Spring-based application or feature that accepts expression-like user input.
2. Confirm or infer that user input is evaluated using Spring Expression Language rather than treated as plain text.
3. Submit a malformed or resource-intensive SpEL expression through the exposed workflow.
4. Cause the vulnerable parser or evaluator to consume excessive CPU, memory, or request-processing time.
5. Repeat or parallelize requests to exhaust application worker threads or degrade service availability.
6. Observe increased latency, errors, failed health checks, or service instability.

How to detect it

Investigate application, web server, API gateway, APM, JVM, and container/orchestrator telemetry for signs of repeated malformed expression submissions followed by resource exhaustion. Useful sources include application logs containing Spring expression parse/evaluation exceptions, HTTP access logs for endpoints that accept rules, filters, templates, formulas, or expression parameters, JVM metrics showing sustained CPU spikes or thread pool saturation, garbage collection logs, Kubernetes restart and liveness/readiness probe failures, and load balancer 5xx/timeout metrics. Look for bursts of 400/500 responses, long request durations, repeated requests from the same source or small set of sources, and exception messages from org.springframework.expression near periods of degraded availability. There are no widely published actor-specific indicators or ransomware-linked campaigns for this issue; detection should focus on behavioral evidence of attempted SpEL abuse and correlated service degradation.

• org.springframework.expression
• org.springframework.expression.spel.SpelParseException
• org.springframework.expression.spel.SpelEvaluationException
• SpelEvaluationException
• SpelParseException
• SpelExpressionParser
• ExpressionParser.parseExpression
• Expression parsing failed
• EL1001E
• EL1008E
• EL1011E
• EL1041E
• EL1042E
• EL1057E
• EL1070E
• java.lang.StackOverflowError
• java.lang.OutOfMemoryError
• Request timed out
• Readiness probe failed
• Liveness probe failed

What your security team should do

• Inventory Spring Framework and spring-expression usage across applications, prioritizing internet-facing services and applications with rule builders, dynamic filters, workflow engines, or template/custom expression features.
• Upgrade Spring Framework 5.3.0 through 5.3.38 and older unsupported versions to a fixed supported release, preferably 5.3.39 or later for the 5.3 line or an appropriate supported 6.x line after compatibility testing.
• Search codebases for user-supplied SpEL evaluation and eliminate it where possible; otherwise restrict it with allowlists, length limits, complexity limits, authentication, and rate limiting.
• Add monitoring for abnormal CPU spikes, request latency, thread pool saturation, repeated expression parse/evaluation errors, and application health-check failures.
• Review WAF/API gateway controls for endpoints that accept expression-like input and apply request body size limits and throttling.
• Because the issue is not in KEV and EPSS is low, prioritize based on actual exposure rather than treating all Spring deployments as equally urgent.
• Verify whether any legacy Ubuntu 14.04 qemu package findings are real in asset inventory and remediate them independently if present.