CVE-2026-59283

Denial of Service
Affects
Spring Framework
in
Spring
No items found.
Versions
<=5.2.25, >=5.3.0 <=5.3.49, >=6.0.0 <=6.0.30, >=6.1.0 <=6.1.28, >=6.2.0 <=6.2.19, >=7.0.0 <=7.0.8
Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

Overview

Spring Framework is a widely used application framework for the Java platform that provides the core programming and configuration model for modern Java enterprise applications, including the Spring Expression Language (SpEL) shipped in the spring-expression module. SpEL expressions are parsed by SpelExpressionParser and evaluated against an EvaluationContext. StandardEvaluationContext exposes the full language, while SimpleEvaluationContext is the restricted context that Spring recommends for expressions that originate outside the application: it limits property access to a configured set of accessors, omits type references, constructors, and bean references, and can enforce read-only semantics. Independently of the context, the parser can be configured to compile frequently evaluated expressions to bytecode through the SpEL compiler, which is switched on with the spring.expression.compiler.mode property or a SpelParserConfiguration that selects the IMMEDIATE or MIXED compiler mode.

A denial of service vulnerability (CVE-2026-59283) has been identified in SimpleEvaluationContext, which allows attackers who can supply SpEL expressions to an application that evaluates them in the restricted context to bypass the guards that context is meant to enforce and to drive unbounded class loading in the server, because SimpleEvaluationContext never opted out of expression compilation. An application is only exposed when the SpEL compiler has been enabled, which it is not by default.

CWE-693 names this failure mode directly: the product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

The advisory rates this vulnerability Medium severity and publishes the CVSS v3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H without a numeric score; the vector corresponds to a computed base score of 6.5, and this entry follows the advisory's Medium rating. The attack vector is Network because the expressions arrive through whatever application input is handed to SpEL, attack complexity is High because the compiler must have been enabled application-wide through a non-default setting and an expression must be evaluated enough times to be compiled, no privileges or user interaction are required, the Confidentiality impact is Low because compiled evaluation can read data the restricted context would otherwise refuse, and the Availability impact is High because each distinct compilable expression causes a new class to be generated and loaded, so an attacker who supplies many distinct expressions can exhaust the memory of the server.

This issue affects Spring Framework <=5.2.25, >=5.3.0 <=5.3.49, >=6.0.0 <=6.0.30, >=6.1.0 <=6.1.28, >=6.2.0 <=6.2.19, and >=7.0.0 <=7.0.8, including the End-of-Life 4.3.x, 5.3.x, 6.1.x, and 6.2.x lines supported by NES for Spring Framework.

Details

Module Info

Vulnerability Info

This Medium-severity vulnerability is found in the spring-expression package in multiple versions of Spring Framework. org.springframework.expression.spel.support.SimpleEvaluationContext is the EvaluationContext implementation designed for evaluating expressions that come from untrusted sources. When an expression is evaluated through it in interpreted mode, every property read, indexer access, and assignment passes through the accessors and flags the context was built with, so the restrictions hold. The SpEL compiler sits outside that arrangement. SpelExpression decides whether to compile an expression purely from the parser's compiler mode, counting interpreted evaluations and compiling the expression once a threshold is crossed, without ever asking the evaluation context whether compilation is acceptable:

private void checkCompile(ExpressionState expressionState) {
    this.interpretedCount.incrementAndGet();
    SpelCompilerMode compilerMode = expressionState.getConfiguration().getCompilerMode();
    if (compilerMode != SpelCompilerMode.OFF) {
        if (compilerMode == SpelCompilerMode.IMMEDIATE) {
            if (this.interpretedCount.get() > 1) {
                compileExpression();
            }
        }
        else {
            // compilerMode = SpelCompilerMode.MIXED
            if (this.interpretedCount.get() > INTERPRETED_COUNT_THRESHOLD) {
                compileExpression();
            }
        }
    }
}

Once a compiled form exists, every getValue overload runs it ahead of the interpreter, again regardless of which context the caller passes in:

@Override
public Object getValue(EvaluationContext context) throws EvaluationException {
    Assert.notNull(context, "EvaluationContext must not be null");

    CompiledExpression compiledAst = this.compiledAst;
    if (compiledAst != null) {
        try {
            return compiledAst.getValue(context.getRootObject().getValue(), context);
        }
        catch (Throwable ex) {
            // If running in mixed mode, revert to interpreted
            if (this.configuration.getCompilerMode() == SpelCompilerMode.MIXED) {
                this.compiledAst = null;
                this.interpretedCount.set(0);
            }
            else {
                // Running in SpelCompilerMode.immediate mode - propagate exception to caller
                throw new SpelEvaluationException(ex, SpelMessage.EXCEPTION_RUNNING_COMPILED_EXPRESSION);
            }
        }
    }

    ExpressionState expressionState = new ExpressionState(context, this.configuration);
    Object result = this.ast.getValue(expressionState);
    checkCompile(expressionState);
    return result;
}

SimpleEvaluationContext provides no way to refuse compilation, so when the SpEL compiler is active, either because spring.expression.compiler.mode was set to IMMEDIATE or MIXED as a JVM system property or in spring.properties, or because the parser was created with a SpelParserConfiguration selecting one of those modes, an expression evaluated in the restricted context is compiled to bytecode like any other. The generated code evaluates the expression directly against the target objects and does not route property access through the context's accessors or consult its read-only and assignment settings, so from the second evaluation onward in IMMEDIATE mode, or after the interpreted threshold in MIXED mode, the safeguards the application relied on are silently no longer applied and the expression can read data the interpreted path would have rejected. The same mechanism also produces the availability impact: each distinct compilable expression is compiled into its own generated class, which is defined in a class loader held by the compiler, so an attacker who can submit a stream of distinct expressions causes the server to keep defining new classes and consuming memory without any limit tied to the restricted context. An expression that was compiled earlier under a StandardEvaluationContext is likewise executed in compiled form if the same Expression instance is later evaluated with a SimpleEvaluationContext.

Applications that leave the SpEL compiler in its default OFF mode are not exposed, because checkCompile() then never compiles anything, but the restricted context accepts compilation in every affected version as soon as the compiler is enabled. The open-ended lower bound of the affected range covers the 4.3.x line as well, where SimpleEvaluationContext has been present since 4.3.15.RELEASE.

This vulnerability was introduced in 2018 with Spring Framework 4.3.15.RELEASE.

Mitigation

Only recent versions of Spring Framework receive community support. The 4.3.x, 5.3.x, 6.1.x, and 6.2.x lines are End-of-Life and will not receive public updates to address this issue, so there is no publicly available fix for those lines other than through a commercial support partner.

Applications that cannot upgrade immediately can avoid the issue by leaving the SpEL compiler in its default OFF mode in any process that evaluates expressions from untrusted sources, that is, by not setting spring.expression.compiler.mode to IMMEDIATE or MIXED and by not constructing the parser used for such expressions with a SpelParserConfiguration that enables compilation, since the issue only arises when compilation is active.

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

  • Upgrade to a currently supported version of Spring Framework. The open-source fix ships in Spring Framework 7.0.9 on the 7.0.x line.
  • Leverage a commercial support partner like HeroDevs for post-EOL security support, which provides the fix for the 4.3.x, 5.3.x, 6.1.x, and 6.2.x lines in nes-v4.3.40, nes-v5.3.54, nes-v6.1.30, and nes-v6.2.21.

Credits

  • This issue was discovered internally by the Spring Framework team. No external finder was credited.
Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
Medium
ID
CVE-2026-59283
PROJECT Affected
Spring Framework
Versions Affected
<=5.2.25, >=5.3.0 <=5.3.49, >=6.0.0 <=6.0.30, >=6.1.0 <=6.1.28, >=6.2.0 <=6.2.19, >=7.0.0 <=7.0.8
NES Versions Affected
Published date
August 29, 2026
≈ Fix date
August 25, 2026
Category
Denial of Service
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Spring
Rss feed icon
Subscribe via RSS
or

By submitting the form I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.