Vulnerability Directory | CVE-2026-41850

Overview

Spring Framework is the foundational application framework for the Java platform, providing core dependency injection, data access, web, and integration support that underpins most of the Spring ecosystem. One of its building blocks is the Spring Expression Language (SpEL), shipped in the spring-expression module, which lets applications parse and evaluate expression strings at runtime to read and write object graphs, invoke methods, build collections, and perform arithmetic. Applications use SpEL directly through SpelExpressionParser and Expression.getValue(...), and indirectly through many Spring features that accept SpEL strings.

A high-severity vulnerability (CVE-2026-41850) has been identified in SpEL expression evaluation. Applications that evaluate user-supplied SpEL expressions are vulnerable to an algorithmic Denial of Service: a short, syntactically valid expression can drive evaluation-time work that grows disproportionately to the size of the expression text, exhausting CPU and memory and degrading or halting availability. The issue only affects applications that evaluate attacker-influenced SpEL; applications that evaluate only static, developer-authored expressions are not exposed.

Per OWASP, a Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed; there are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resource-handling vulnerabilities, among others. This vulnerability is the resource-handling variant: a crafted expression forces the evaluator to perform an outsized amount of work, consuming the resources that legitimate requests depend on.

The CVSS v3.1 base score vector for this vulnerability is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (High). The attack vector is Network because the malicious expression can arrive over a normal application request, attack complexity is Low because a single crafted expression is sufficient, and no privileges or user interaction are required. The impact is Availability-only and High: the evaluation path consumes resources but does not disclose or modify data, so there is no confidentiality or integrity impact. This is classified under CWE-770 (Allocation of Resources Without Limits or Throttling).

This issue affects Spring Framework >=4.3.0 <=4.3.30, >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, and >=7.0.0 <=7.0.7.

‍

Details

Module Info

Product: Spring Framework
Affected packages: spring-expression
Affected versions: >=4.3.0 <=4.3.30, >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, >=7.0.0 <=7.0.7
GitHub repository: https://github.com/spring-projects/spring-framework
Published packages: https://central.sonatype.com/artifact/org.springframework/spring-expression
Package manager: Maven
Fixed in:
NES for Spring Framework 4.3.x, 5.3.x, 6.1.x
Spring Framework 6.2.19, 7.0.8 (OSS)

Vulnerability Info

The vulnerability lives in the SpEL evaluation engine in the spring-expression module. When SpEL evaluates a parsed expression, it walks an abstract syntax tree (AST) of nodes such as inline lists and maps (InlineList, InlineMap), indexers (Indexer), arithmetic and comparison operators (OpPlus, OpMultiply, OpMinus, and the comparison/logical operators), method, constructor, function, and bean references, and assignment/increment/decrement nodes. Each node performs its work and recurses into its children to produce a result.

Prior to the fix, evaluation had no cap on the total number of operations it would perform. The existing guards from CVE-2023-20863 bound only sizes, expression text (maximumExpressionLength, default 10000 characters) and any single concatenated string (100000 characters), not evaluation-time work. Nested inline collections, unbounded repetition of bounded-size concatenations, and operands that grow as evaluation proceeds let a short expression that passes every size check consume CPU and memory far out of proportion to its size, starving legitimate requests.

Pre-fix, an AST node such as InlineList constructed its result by evaluating every child with no per-operation accounting:‍

List<Object> returnValue = new ArrayList<>(childCount);for (int c = 0; c < childCount; c++) {    returnValue.add(getChild(c).getValue(expressionState));}

The fix counts operations during evaluation and throws a SpelEvaluationException past a cap of 10000 operations by default, configurable per parser via SpelParserConfiguration or globally via spring.expression.maxOperations. Well-behaved expressions stay far below the threshold and are unaffected.

‍

Mitigation

Only recent versions of Spring Framework receive community support and updates. The 6.1.x and 5.3.x lines are out of OSS support and have no publicly available OSS fix for this vulnerability; their upstream fixes are available only through commercial maintenance, and older lines such as 4.3.x have no public fix at all.

This issue is exploitable only where an application evaluates attacker-influenced SpEL expressions. Applications that evaluate only static, developer-authored expressions are not exposed, and reviewing where untrusted input reaches SpEL evaluation is a useful first step.

Users of the affected components should apply one of the following mitigations:

Upgrade to a currently supported version of Spring Framework. The OSS fix ships in Spring Framework 6.2.19 (6.2.x line) and 7.0.8 (7.0.x line). On a fixed version, the evaluation-time operation limit can be tuned with the spring.expression.maxOperations property if an application's legitimate expressions need a higher or lower bound.
Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring Framework, which provides the fix for the 4.3.x, 5.3.x, and 6.1.x lines.