CVE-2026-41849

What it actually does

This is a denial-of-service vulnerability in Spring Expression Language (SpEL) evaluation logic affecting Spring Framework 5.3.0 through 5.3.48. A specially crafted SpEL expression can trigger an integer overflow condition during expression evaluation, causing excessive CPU, memory, or execution-time consumption. Successful exploitation impacts availability only; it does not directly provide code execution, data disclosure, or privilege escalation. The practical exposure depends on whether an application accepts attacker-controlled input that is parsed or evaluated as SpEL.

Why it matters to the business

Applications that expose SpEL evaluation to unauthenticated or low-privileged users may be forced into degraded performance or outage by malicious requests. This can interrupt customer-facing services, APIs, batch processing, or internal business workflows that depend on affected Spring-based applications. Although the EPSS score is currently low and stable, there is no CISA KEV listing, no known ransomware association, and no mature public exploit reported, the flaw is network-accessible, low-complexity, and affects a widely used application framework, so internet-facing systems should still be prioritized for review and remediation.

How an attack unfolds

An attacker first identifies an application path where user-controlled input is interpreted as a Spring Expression Language expression, such as dynamic filters, rule engines, template logic, search expressions, workflow conditions, or administrative expression-evaluation features. The attacker then submits a deliberately malformed or computationally expensive SpEL payload designed to trigger the vulnerable integer-overflow behavior in the evaluator. When the server parses or evaluates the expression, resource consumption spikes and application worker threads may become blocked, exhausted, or terminated. Repeating the request can amplify the effect, leading to high latency, HTTP 5xx responses, failed health checks, container restarts, or complete service unavailability. Systems that never evaluate untrusted SpEL input are less likely to be exploitable even if the vulnerable library is present.

How to fix it

Upgrade affected Spring Framework 5.3.x deployments to a vendor-fixed or otherwise unaffected version as soon as it is available. Because the provided advisory data lists Spring Framework 5.3.0 through 5.3.48 as affected and does not provide an exact fixed version, confirm the remediated version from the official Spring advisory and package metadata before release. Review direct and transitive dependencies, especially spring-expression and spring-core artifacts pulled through Spring Framework or Spring Boot dependency management. Where immediate upgrade is not possible, remove or restrict functionality that evaluates user-controlled SpEL, require authentication and authorization for expression-evaluation features, enforce strict expression allowlists, limit expression length and complexity, add request rate limits, configure application timeouts, and ensure container or JVM resource limits prevent one service from exhausting shared infrastructure.

How to confirm the fix worked

Confirm exposure by checking software composition analysis, SBOMs, Maven dependency trees, Gradle dependency reports, container image manifests, and deployed JAR files for Spring Framework versions 5.3.0 through 5.3.48, particularly the spring-expression artifact. Validate remediation by confirming the deployed runtime no longer contains affected Spring Framework or spring-expression versions. Review application code and configuration for use of SpelExpressionParser, ExpressionParser, StandardEvaluationContext, @Value expressions sourced from external input, dynamic rule engines, or template paths that may evaluate user input. In a non-production environment, test representative expression-handling endpoints with safe negative test cases to confirm untrusted input is rejected, length-limited, or not evaluated as SpEL. Also confirm that monitoring shows normal CPU, memory, thread pool, garbage collection, and error-rate behavior after the fix.

Typical attack path

1. Identify Spring-based applications or APIs that appear to process dynamic expressions, filters, templates, rules, or scripted conditions.
2. Probe inputs with benign SpEL syntax to determine whether user-supplied content is evaluated by SpEL.
3. Send a crafted SpEL expression intended to trigger excessive resource consumption in the vulnerable evaluation logic.
4. Repeat or parallelize requests to consume application CPU, memory, or request-handling threads.
5. Observe degraded response times, timeouts, HTTP 5xx errors, failed health checks, or service restarts as the denial-of-service condition takes effect.

How to detect it

Look for evidence of attempted or successful denial of service rather than data theft. Useful sources include web access logs, application logs, API gateway logs, WAF logs, load balancer logs, APM traces, JVM metrics, garbage-collection logs, Kubernetes or container restart events, host CPU and memory telemetry, and application thread dumps. Hunt for bursts of requests to endpoints that accept filters, rules, templates, search expressions, workflow conditions, or other dynamic expression inputs, especially requests containing SpEL-like syntax such as '#{', '${', 'T(', 'new ', method calls, nested property traversal, projections, or selections. Correlate those requests with sudden increases in request duration, HTTP 408/429/500/502/503/504 responses, worker thread exhaustion, JVM out-of-memory events, excessive garbage collection, pod restarts, or failed health checks. In thread dumps or stack traces, look for many active threads inside org.springframework.expression.spel evaluation classes. Because there are no reported public exploit indicators or known threat actors for this CVE, detection should focus on behavioral anomalies and repeated SpEL parsing/evaluation failures near availability incidents.

• org.springframework.expression.spel
• org.springframework.expression.spel.standard.SpelExpressionParser
• org.springframework.expression.spel.SpelEvaluationException
• org.springframework.expression.spel.SpelParseException
• org.springframework.expression.ExpressionParser
• org.springframework.expression.Expression
• org.springframework.expression.spel.ExpressionState
• java.lang.OutOfMemoryError
• java.lang.StackOverflowError
• GC overhead limit exceeded
• OutOfMemoryError: Java heap space
• HTTP 503
• HTTP 504
• #{
• ${
• T(
• new

What your security team should do

• Inventory all applications and container images using Spring Framework 5.3.0 through 5.3.48, including transitive dependencies.
• Prioritize internet-facing, unauthenticated, API-heavy, or rule/template-driven applications that may evaluate user-controlled SpEL.
• Upgrade to an official fixed or unaffected Spring Framework version once verified from the vendor advisory; do not rely only on top-level application version names.
• Until patched, disable or restrict any feature that evaluates externally supplied SpEL expressions.
• Add input length limits, expression allowlists, authentication checks, rate limits, request timeouts, and JVM/container resource ceilings around expression-processing paths.
• Create detection rules for repeated requests containing SpEL-like syntax followed by CPU, memory, garbage-collection, thread-exhaustion, timeout, or HTTP 5xx spikes.
• Review logs for the period since publication, especially around unexplained service degradation or restarts.
• Ensure incident response runbooks include collection of application logs, access logs, thread dumps, heap dumps when safe, container restart events, and load balancer health-check failures.