Spring Framework CVE-2026-41849: Overview of SpEL Integer Overflow Denial of Service in an EOL Branch

Introduction

An integer overflow in Spring Framework's SpEL evaluation engine lets an unauthenticated remote attacker cause denial of service by submitting a crafted expression that triggers excessive resource consumption. The CVSS 7.5 rating is only part of the operational problem. Spring Framework 5.3 reached its open-source end of life in August 2024, so the only patch for the affected 5.3.x branch is gated behind a commercial support subscription.

CVE-2026-41849 is also the second SpEL-related denial of service vulnerability disclosed in recent history, after CVE-2024-38808. With SpEL weaknesses recurring and the branch past its end of life, many organizations running Spring 5.3.x may be unable to patch through normal channels.

Technical Information

Root Cause: Integer Overflow in SpEL Evaluation

CVE-2026-41849 is classified under CWE-190 (Integer Overflow or Wraparound). Per the MITRE definition, this occurs when an integer value is incremented beyond the maximum value that its representation can store, so the value wraps around to an incorrect result. Here, an arithmetic operation in the SpEL evaluation engine exceeds the integer type's capacity, and the wraparound leads to uncontrolled resource consumption.

The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, which breaks down as follows:

Put together, these values mean that any network-accessible Spring application that processes SpEL expressions from untrusted sources is exploitable without preconditions.

SpEL Attack Surface

The Spring Expression Language (SpEL) is an expression language for querying and manipulating an object graph at runtime. The SpelExpressionParser class parses SpEL expressions and returns an Expression instance that can be evaluated. SpEL injection occurs when an application passes user-controlled data directly to the SpEL expression parser without sanitization.

A classic vulnerable pattern is a controller endpoint that passes raw input straight to the SpEL parser:

private static final SpelExpressionParser PARSER = new SpelExpressionParser();
private static final StandardEvaluationContext CONTEXT = new StandardEvaluationContext();

@PostMapping(path = "/")
public void method(@RequestBody String path, @RequestBody String value) {
    Expression expression = PARSER.parseExpression(path);
    expression.setValue(CONTEXT, value);
}

CVE-2026-41849 differs from the typical SpEL RCE pattern (e.g., payloads like T(java.lang.Runtime).getRuntime().exec('id')). The attacker crafts a SpEL expression that triggers an integer overflow in the evaluation engine itself. The evaluator then consumes excessive resources, and the application becomes unavailable.

Evaluation Context Does Not Fully Mitigate This Issue

Spring provides two primary evaluation context implementations:

Using SimpleEvaluationContext is a well-known defensive measure against SpEL injection RCE:

EvaluationContext simpleContext = SimpleEvaluationContext.forReadOnlyDataBinding().build();
Expression exp = parser.parseExpression("T(java.lang.Runtime).getRuntime().exec('id')");
// exp.getValue(simpleContext); // throws an error - reflection blocked

It does not fully protect against availability attacks, though. SimpleEvaluationContext is documented as still susceptible to Regular Expression Denial of Service (ReDoS) via expressions like 'aaaaaaaaaaaaaaaaaaaaaaaa!'.matches('^(a+)+$'). CVE-2026-41849 extends this pattern. The integer overflow occurs in the evaluation engine itself, not in the expression's reflective capabilities, so context-level safeguards that focus on blocking reflection may not prevent exploitation.

Comparison With CVE-2024-38808

CVE-2024-38808, the earlier SpEL DoS vulnerability, was described as a DoS condition triggered by a "specially crafted Spring Expression Language (SpEL) expression" and was rated medium severity. The key differences:

The higher severity rating for CVE-2026-41849 and its specific CWE-190 classification indicate that this integer overflow variant may enable more reliable or more severe DoS outcomes. The recurrence of SpEL DoS vulnerabilities suggests a systemic issue in the expression evaluation engine, one that needs deeper architectural remediation than point patches.

Attack Flow

From the available information, exploitation follows this general sequence:

1. The attacker identifies a Spring application endpoint that accepts input which flows into SpEL expression evaluation. Common patterns include @Value annotations with dynamic content, data binding configurations, or explicit SpelExpressionParser.parseExpression() calls on user-supplied data.
2. The attacker submits a specially crafted SpEL expression designed to trigger an integer overflow in the evaluation engine's arithmetic operations.
3. The overflow wraps around, and the evaluation engine starts consuming excessive resources (CPU, memory, or both).
4. The application stops responding, which denies service to legitimate users.

The specific expression that triggers the overflow has not been publicly disclosed. The Spring advisory does not provide proof-of-concept code, and no public source-level commit diff for the integer overflow fix has been released yet.

Patch Information

The Spring team fixed the integer overflow in the SpEL evaluation engine in a vendor-published release. According to the official advisory, published on June 8, 2026, the fix version for the 5.3.x branch is 5.3.49.

Because the 5.3.x line has reached the end of open-source support, version 5.3.49 is distributed only through Tanzu Spring Enterprise, a commercial support channel operated by VMware/Broadcom. There is no freely downloadable OSS release or publicly visible commit diff for the 5.3.x fix.

Users on newer branches have an easier path. Spring Framework 7.0.8 and 6.2.19, released together on June 8, 2026, list CVE-2026-41849 among the 18 CVEs they address, and both are publicly available OSS releases. The release notes for v7.0.8 and v6.2.19 also reference SpEL-related improvements, notably issue #36801 ("Eagerly compute exit descriptors for negative literals") and #36756 ("Improve error messages in SpEL"). These point to hardening work in the SpEL engine that shipped alongside the security fixes. The 6.2.x and 7.0.x codebases went through significant refactoring of SpEL internals in earlier major versions, so the integer overflow pathway that existed in 5.3.x was likely already absent or substantially different in these newer lines, with the June 2026 releases adding defense in depth.

VMware has signaled that 6.2.19 is likely the last OSS release of the 6.2.x generation and has encouraged users to migrate to 7.0.x at their earliest convenience.

The recommended upgrade paths are:

• 5.3.x users: Upgrade to 5.3.49 via commercial Tanzu Spring support, or preferably migrate to 6.2.19 or 7.0.8.
• 6.2.x users: Upgrade to 6.2.19 (publicly available).
• 7.0.x users: Upgrade to 7.0.8 (publicly available).

Defensive Coding Practices (Where Immediate Patching Is Not Feasible)

The following measures reduce the attack surface, but the Spring advisory does not confirm them as sufficient substitutes for the patch:

1. Always prefer SimpleEvaluationContext over StandardEvaluationContext when evaluating expressions derived from external input. It disables reflection-based method invocation, though it may not block the integer overflow DoS specifically.

2. Validate any user-supplied data destined for expression evaluation against a strict allowlist of expected patterns and values.

3. Run static analysis (SAST) over the source code and search for vulnerable patterns using keywords such as SpelExpressionParser, EvaluationContext, parseExpression, or @Value("#{ ... }"). CodeQL provides a specialized query, java/spel-expression-injection, designed to detect tainted data flowing into SpEL parsing methods.

4. The most fundamental mitigation is to make sure untrusted user input never flows unvalidated into the SpEL expression parser.

Affected Systems and Versions

The vulnerability affects Spring Framework 5.3.0 through 5.3.48. Any application running a version in this range that evaluates SpEL expressions is vulnerable, particularly when those expressions are exposed to untrusted input.

Common vulnerable configurations include:

• Spring Boot applications using @Value annotations with dynamic or externally influenced content
• Applications using SpelExpressionParser.parseExpression() with user-controlled input
• Data binding configurations that use SpEL for expression evaluation
• Any endpoint or service that passes external input into SpEL evaluation, regardless of whether StandardEvaluationContext or SimpleEvaluationContext is used

The fix is available in:

• 5.3.49 (commercial, via Tanzu Spring Enterprise)
• 6.2.19 (public OSS release)
• 7.0.8 (public OSS release)

Vendor Security History

Spring Framework has a documented history of SpEL-related vulnerabilities spanning multiple years and sub-projects:

SpEL vulnerabilities keep recurring, as both RCE and DoS, across Core Framework, Cloud Function, and Spring AI. That pattern reveals a systemic challenge in expression language sandboxing within the Spring ecosystem. The Spring team discovers some vulnerabilities internally and responds with patches, but the EOL model for major versions leaves remediation gaps for organizations that have not migrated or purchased extended support.

The Spring security advisories page documents an ongoing stream of CVEs across the Spring portfolio. Recent entries include CVE-2026-40983 (Micrometer gRPC server instrumentation DoS, HIGH) and CVE-2026-40973 (predictable temp directory), published June 8, 2026, just one day before CVE-2026-41849.

The Canadian Centre for Cyber Security has issued formal advisories (AV26-288) covering Spring security advisories, which indicates that national cybersecurity authorities consider the SpEL attack surface significant enough to warrant government-level alerts.

Spring4Shell (CVE-2022-22965) was exploited in the wild soon after disclosure, with the first attacks identified on March 30, 2022. CVE-2022-22963 was also actively exploited, via HTTP request header injection. CVE-2026-41849 had no confirmed exploitation in the wild as of its publication date, but Spring SpEL vulnerabilities have a history of rapid exploitation, and that history argues for treating this as a high-priority remediation task.

References

• CVE-2026-41849 Official Spring Advisory
• CVE-2026-41849 NVD Detail
• Spring Framework 7.0.8 and 6.2.19 Release Announcement
• Spring Framework v7.0.8 Release Notes
• Spring Framework v6.2.19 Release Notes
• CVE-2026-41849 on CVEFeed
• Spring Security Advisories
• CVE-2024-38808: Spring Expression DoS Vulnerability
• CWE-190: Integer Overflow or Wraparound
• SpEL Injection Cheat Sheet
• CodeQL: Expression Language Injection (Spring)
• Spring Framework End of Life Dates
• Spring 5 End of Life Explained (TuxCare)
• HeroDevs: Spring Framework April 2026 CVEs
• CVE-2024-38808 Vulnerability Directory (HeroDevs)
• Exploitation of Spring4Shell in the Wild
• Detecting and Mitigating CVE-2022-22963 (Sysdig)
• CVE-2026-22738: Spring AI SpEL Injection RCE (SentinelOne)
• Spring Security Advisory AV26-288 (Canadian Centre for Cyber Security)
• CISA Known Exploited Vulnerabilities Catalog