CVE-2026-41850

What it actually does

This vulnerability affects applications that evaluate user-supplied Spring Expression Language (SpEL) expressions using vulnerable Spring Framework versions. A specially crafted expression can cause algorithmic complexity during parsing or evaluation, consuming excessive CPU and/or memory. Because the attack is network-accessible, low-complexity, and requires no authentication or user interaction when an exposed application accepts untrusted expressions, successful exploitation can degrade service performance or make the application unavailable. The impact is availability-only; it does not directly provide code execution, data disclosure, or privilege escalation based on the provided information.

Why it matters to the business

An attacker may be able to make affected Spring-based applications slow, unstable, or unavailable by sending crafted input to functionality that evaluates SpEL expressions. For internet-facing services, this can result in customer-facing outages, failed transactions, degraded APIs, increased infrastructure costs from resource exhaustion, and incident response disruption. Although EPSS is currently low and there is no known KEV listing or ransomware association, the CVSS score is high for availability impact, and organizations with public endpoints that evaluate user-controlled expressions should treat exposure as operationally significant.

How an attack unfolds

An attacker first identifies an application endpoint or feature that accepts input later evaluated as a Spring Expression Language expression. The attacker then submits a crafted SpEL payload designed to trigger worst-case or highly expensive evaluation behavior in the vulnerable Spring Framework implementation. When the application evaluates the expression, CPU, memory, or execution time increases disproportionately compared with the request size. Repeating the request, or sending it concurrently, can exhaust application worker threads, saturate CPU, trigger garbage collection pressure, increase latency, and eventually cause timeouts, health-check failures, or service unavailability. No authentication is required if the vulnerable expression-evaluation path is exposed anonymously; otherwise, exploitation depends on access to a feature that accepts SpEL input.

How to fix it

Upgrade affected Spring Framework deployments to a vendor-provided fixed version as soon as one is available for the relevant supported release line. The vulnerable version ranges are Spring Framework 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, and 5.3.0 through 5.3.48. Where immediate upgrade is not possible, remove or redesign features that evaluate user-supplied SpEL expressions, treat user input as data rather than executable expressions, enforce strict allowlists for permitted expression constructs, apply length and complexity limits, add request rate limiting, set evaluation timeouts where feasible, isolate expression evaluation from critical request paths, and monitor resource consumption. Avoid blacklists as the primary control because expression languages often provide multiple syntactic paths to similar behavior.

How to confirm the fix worked

Confirm software composition inventories, build manifests, dependency lockfiles, and runtime classpaths no longer include affected Spring Framework versions. Validate that any application functionality accepting user-controlled input does not pass that input directly into SpEL parsers or evaluators. Perform negative testing with oversized, deeply nested, and complex expression-like inputs in a controlled environment and verify that requests are rejected, bounded, or timed out without causing abnormal CPU, memory, garbage collection, or thread-pool exhaustion. Confirm web application firewall, gateway, or application-level rate limits are active for endpoints that process expression-like input. After remediation, monitor application latency, 5xx rates, JVM CPU, heap usage, GC pauses, and thread utilization under test traffic to ensure resource usage remains bounded.

Typical attack path

1. Discover a Spring-based application or API feature that accepts expression-like user input.
2. Confirm that submitted input is evaluated as Spring Expression Language rather than treated as plain text.
3. Send crafted SpEL expressions intended to cause expensive parsing or evaluation behavior.
4. Observe increased response time, timeouts, elevated CPU, memory pressure, or application errors.
5. Automate or parallelize requests to sustain resource exhaustion and degrade service availability.

How to detect it

To determine whether exploitation may already have occurred, correlate application, web server, load balancer, API gateway, APM, JVM, container, and infrastructure telemetry. Look for short bursts or sustained waves of requests to endpoints that accept expression-like input followed by increased latency, request timeouts, 5xx errors, CPU saturation, heap growth, garbage collection pauses, container restarts, health-check failures, or thread-pool exhaustion. Application logs may show repeated SpEL parsing or evaluation exceptions, request validation failures, or unusually long evaluation times if instrumented. Web and API logs should be searched for repeated parameters or bodies containing SpEL-like syntax, especially from a small set of source IPs or user agents and especially when paired with resource exhaustion. Because there are no public exploit indicators provided and this is a denial-of-service condition, detection should emphasize behavioral correlation rather than relying on a single signature.

• SpelEvaluationException
• SpelParseException
• org.springframework.expression
• org.springframework.expression.spel
• T(
• #root
• #this
• ?.
• ^[
• .$[

What your security team should do

• Inventory all applications using Spring Framework and prioritize those on versions 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, or 5.3.0-5.3.48.
• Identify endpoints, APIs, administrative features, workflow engines, rule engines, template systems, search filters, or configuration interfaces that evaluate user-provided SpEL expressions.
• Upgrade to vendor-fixed Spring Framework releases when available, prioritizing internet-facing and unauthenticated expression-evaluation paths.
• Until patched, disable user-supplied SpEL evaluation or enforce strict allowlists, input size limits, evaluation limits, and rate limiting.
• Add monitoring and alerting for sudden spikes in CPU, heap usage, GC pauses, request latency, 5xx responses, and application thread exhaustion on Spring services.
• Review recent logs for repeated expression parse/evaluation errors, unusual expression-like request payloads, and correlated resource exhaustion events.
• If exploitation is suspected, preserve application logs, access logs, JVM metrics, thread dumps, heap diagnostics if safe to collect, and load balancer or API gateway telemetry for incident analysis.