spring-expression Security: SpEL Risks and How to Contain Them

The spring-expression library provides the Spring Expression Language (SpEL), and its central security lesson is simple: never evaluate an expression built from untrusted input, because SpEL can invoke methods and drive resource consumption in ways that lead to remote code execution or denial of service. The org.springframework:spring-expression artifact is a core Spring dependency, so it ends up on nearly every Spring classpath. This guide explains where the danger comes from, which recent CVEs affect it, and the patterns that keep expression evaluation safe.

What spring-expression is and why it is powerful

SpEL is a runtime expression language. It can read and write object properties, call methods, index collections, and invoke constructors, all from a string evaluated at runtime. That power is what makes it useful for Spring Security expressions, @Value annotations, and templating. It is also exactly what makes it dangerous when the string comes from a user.

A minimal evaluation looks like this:

ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression("'Hello ' + name");
String result = (String) exp.getValue(context);

Because SpEL can reach arbitrary methods on objects in scope, an attacker who controls the expression string can potentially call T(java.lang.Runtime).getRuntime().exec(...). That is the root of SpEL injection: user-controlled expressions are code, not data.

The injection risk: user input as an expression

The vulnerable pattern is any place where a request parameter, header, or stored value flows into parseExpression:

// Dangerous: the expression string comes from the request
String userInput = request.getParameter("filter");
Expression exp = parser.parseExpression(userInput);
Object value = exp.getValue(context);

If filter contains a T(...) type reference or a chained method call, the evaluator will run it. This is a well-known class of vulnerability in Spring applications and has been the mechanism behind several historically severe issues. The defense is categorical: do not parse untrusted strings as SpEL. If you need user-driven filtering, use a purpose-built query API or a strict allowlist, not a general-purpose expression evaluator.

The 2026 SpEL CVEs

On June 8, 2026, the Spring team published four SpEL vulnerabilities in the spring-expression component. They are worth knowing because they affect a broad range of maintained versions:

• CVE-2026-41852 — Arbitrary zero-argument method invocation during SpEL evaluation, even in restricted or read-only contexts. Affected versions include Spring Framework 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, and 5.3.0-5.3.48.
• CVE-2026-41850 — Algorithmic denial of service when a crafted expression triggers excessive resource consumption during evaluation. Same affected ranges.
• CVE-2026-41851 — Denial of service via unbounded cache growth leading to memory exhaustion. Same affected ranges.
• CVE-2026-41849 — Denial of service via integer overflow in SpEL evaluation logic, affecting Spring Framework 5.3.0 through 5.3.48.

The common thread is that applications evaluating user-supplied SpEL expressions are the ones at risk. Upgrade to the patched releases the advisories name, and confirm your transitive spring-expression version, since it is often pulled in indirectly rather than declared. Two earlier DoS issues, CVE-2023-20863 and CVE-2024-38808, follow the same theme in older versions.

Find where spring-expression actually lives in your build

Because spring-expression is a transitive dependency of spring-context and much of the Spring ecosystem, teams frequently do not realize which version they ship. Print the resolved version before you assume:

# Maven
mvn dependency:tree -Dincludes=org.springframework:spring-expression

# Gradle
./gradlew dependencyInsight --dependency spring-expression

Pin the version through Spring's BOM rather than overriding a single artifact, so the whole framework stays consistent. An SCA tool such as Safeguard can flag a vulnerable spring-expression version transitively and tell you which top-level dependency dragged it in, which is the part dependency:tree makes you hunt for by hand.

Safe patterns for expression evaluation

If you genuinely need SpEL at runtime, constrain it:

• Use SimpleEvaluationContext instead of StandardEvaluationContext when evaluating anything that might be influenced by user data. The simple context deliberately omits type references, bean references, and constructor invocation, cutting off the most dangerous capabilities.

EvaluationContext context = SimpleEvaluationContext
    .forReadOnlyDataBinding()
    .build();

• Keep the expression string static. Let users supply data that the expression operates on, never the expression itself.
• Prefer a domain-specific alternative. For search filters, a query builder or parameterized criteria API gives you the flexibility without an eval engine.

SimpleEvaluationContext is the single most effective control here, because it removes the reflective reach that turns SpEL injection into code execution.

Build a repeatable check into CI

Treat spring-expression like any other supply-chain dependency: verify its version on every build and fail the pipeline on a known-vulnerable release. Combine a dependency scan with a static-analysis rule that flags parseExpression calls taking non-constant arguments, so a new instance of the injection pattern cannot merge unnoticed. Our Academy has broader guidance on wiring dependency and static checks into a pipeline.

FAQ

What is spring-expression used for?

It is the artifact that implements the Spring Expression Language (SpEL), a runtime language for querying and manipulating objects. Spring uses it for @Value injection, security expressions, and templating. It is a core, usually transitive, dependency across the Spring ecosystem.

Why is SpEL a security risk?

SpEL can invoke methods, reference types, and call constructors from a string evaluated at runtime. If that string is built from untrusted input, an attacker can execute arbitrary code (SpEL injection) or craft expressions that exhaust resources (denial of service).

How do I evaluate SpEL safely?

Never parse untrusted input as an expression. When you must evaluate expressions influenced by external data, use SimpleEvaluationContext rather than StandardEvaluationContext, keep the expression template static, and let users supply only the data operated on.

Which Spring versions are affected by the 2026 SpEL CVEs?

The June 2026 advisories (CVE-2026-41849/41850/41851/41852) affect broad ranges of Spring Framework including 5.3.x up to 5.3.48, 6.1.x, 6.2.x, and 7.0.x up to 7.0.7, depending on the specific CVE. Check each advisory and upgrade to the patched release it names, verifying your transitive spring-expression version.