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 allows an unauthenticated remote attacker to cause denial of service by submitting a crafted expression that triggers excessive resource consumption. What makes this particular vulnerability operationally significant is not just its CVSS 7.5 rating, but the fact that the only patch for the affected 5.3.x branch is gated behind a commercial support subscription, since Spring Framework 5.3 reached its open source end of life in August 2024.

CVE-2026-41849 is the second SpEL related denial of service vulnerability disclosed in recent history, following CVE-2024-38808. The pattern of recurring SpEL weaknesses, combined with the remediation constraints imposed by the end of life status, creates a situation where many organizations running Spring 5.3.x may find themselves 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 the associated representation can store, causing the value to wrap around to an incorrect result. In the context of this vulnerability, an arithmetic operation within the SpEL evaluation engine exceeds the integer type's capacity, and the resulting wraparound behavior 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:

This combination of characteristics means any network accessible Spring application that processes SpEL expressions from untrusted sources is exploitable without any preconditions.

SpEL Attack Surface

The Spring Expression Language (SpEL) is a powerful expression language that supports querying and manipulating an object graph at runtime. SpEL expressions are parsed using the SpelExpressionParser class, which 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 involves a controller endpoint that takes raw input and passes it 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);
}

For CVE-2026-41849, the attack does not follow the typical SpEL RCE pattern (e.g., payloads like T(java.lang.Runtime).getRuntime().exec('id')). Instead, the attacker crafts a SpEL expression that triggers an integer overflow in the evaluation engine itself, causing the evaluator to consume excessive resources and rendering the application 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

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

Comparison With CVE-2024-38808

This is the second SpEL DoS vulnerability in recent history. CVE-2024-38808 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, combined with the specific CWE-190 classification, indicates this integer overflow variant may enable more reliable or severe DoS outcomes. The recurrence of SpEL DoS vulnerabilities suggests a systemic issue in the expression evaluation engine that requires deeper architectural remediation beyond point patches.

Attack Flow

Based on 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 integer overflow causes wraparound behavior, leading the evaluation engine into a state of excessive resource consumption (CPU, memory, or both).
4. The application becomes unresponsive, resulting in denial of service for legitimate users.

The specific crafted 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 at this time.

Patch Information

The Spring team addressed CVE-2026-41849 through a vendor published fix that corrects the integer overflow in the SpEL evaluation engine. According to the official advisory published on June 8, 2026, the designated fix version for the 5.3.x branch is 5.3.49.

The availability of this patch is nuanced. Because the 5.3.x line has reached end of open source support, version 5.3.49 is distributed exclusively 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.

For users on more recent branches, the situation is more favorable. The concurrent release of Spring Framework 7.0.8 and 6.2.19 on June 8, 2026 included CVE-2026-41849 in its umbrella list of 18 addressed CVEs. Both of these are publicly available OSS releases. The release notes for v7.0.8 and v6.2.19 reference SpEL related improvements, notably issue #36801 ("Eagerly compute exit descriptors for negative literals") and #36756 ("Improve error messages in SpEL"), which indicate hardening work in the SpEL engine that shipped alongside the security fixes. Since the 6.2.x and 7.0.x codebases underwent significant refactoring of SpEL internals in prior major versions, 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 providing additional defense in depth.

VMware has signaled that 6.2.19 is likely the last OSS release of the 6.2.x generation, encouraging 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)

Where immediate patching is not feasible, the following measures reduce the attack surface but are not confirmed by the Spring advisory as sufficient substitutes for the patch:

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

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

3. Apply static analysis (SAST): Scan source code for vulnerable patterns by searching for 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. Never allow untrusted input into the SpEL parser: The most fundamental mitigation is to ensure 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 within this range that evaluates SpEL expressions, particularly those exposed to untrusted input, is vulnerable.

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 leverage 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:

The recurring nature of SpEL vulnerabilities, from RCE to DoS, across Core Framework, Cloud Function, and Spring AI, 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 creates 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, indicating that national cybersecurity authorities consider the SpEL attack surface significant enough to warrant government level alerts.

Spring4Shell (CVE-2022-22965) was rapidly exploited in the wild after disclosure, with attacks first identified on March 30, 2022. CVE-2022-22963 was also actively exploited via HTTP request header injection. While CVE-2026-41849 has no confirmed wild exploitation as of its publication date, the historical precedent for rapid exploitation of Spring SpEL vulnerabilities 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