Spring Framework CVE-2026-41850: Brief Summary of the SpEL Algorithmic Denial of Service Vulnerability

Introduction

A crafted Spring Expression Language (SpEL) input can now bring down a Spring Framework application without authentication, without user interaction, and with minimal effort on the attacker's part. CVE-2026-41850 is an algorithmic denial-of-service vulnerability with a CVSS score of 7.5 (HIGH). It affects four major Spring Framework version branches, which together span nearly the entire active and legacy support window.

The vulnerability also continues a pattern. It is the third publicly disclosed SpEL DoS vulnerability in Spring Framework, after CVE-2023-20861 and CVE-2024-38808, and it arrives alongside what Broadcom calls the "largest set" of Spring security updates in the framework's 23-year history. The three scores went from 5.3 to 4.3 and now to 7.5, and this latest exploitation path in the SpEL engine is the most damaging of the three.

Technical information

Root cause: algorithmic complexity in SpEL evaluation

NVD classifies CVE-2026-41850 as CWE-407 (Inefficient Algorithmic Complexity), and the Spring advisory adds CWE-770 (Allocation of Resources Without Limits or Throttling). CWE-407 describes a weakness where "an algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached." It belongs to a well-studied family of algorithmic DoS weaknesses. It is a child of CWE-405 (Asymmetric Resource Consumption) and a parent of CWE-1333 (Inefficient Regular Expression Complexity).

SpEL is a runtime expression evaluation engine used throughout the Spring Framework. When an application accepts and evaluates untrusted or user-controlled SpEL expressions, an attacker can supply a specially crafted expression that forces the SpEL evaluation engine into a worst-case computational path. In algorithmic complexity attacks, this typically involves exploiting hash collision worst cases, recursive nesting, or data structure operations that degrade from average-case O(1) or O(n) to worst-case O(n^2) or worse. A relatively small, carefully constructed input then consumes disproportionate CPU cycles or memory during expression evaluation.

CVSS breakdown

The CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, which gives a base score of 7.5 (HIGH):

Compared with the prior CVE-2024-38808 (CVSS 4.3, vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L), CVE-2026-41850 requires no user interaction (UI:N versus UI:R) and causes high availability impact (A:H versus A:L). Those two changes nearly double the CVSS score.

Attack flow

The exploitation follows a straightforward path:

1. The attacker locates a Spring Framework endpoint that accepts user input and passes it to the SpEL evaluation engine. Common scenarios include web endpoints that evaluate SpEL expressions from request parameters or headers, rule engines or dynamic configuration systems that accept SpEL from external sources, and data filtering or query mechanisms that incorporate user-supplied SpEL expressions.

2. The attacker constructs a SpEL expression designed to trigger the worst-case algorithmic complexity in the evaluation engine. The exact structure of the crafted expression has not been publicly disclosed, consistent with Spring's responsible disclosure practice.

3. The attacker sends the crafted expression over HTTP, since the attack vector is network based (AV:N). The attack needs no authentication (PR:N) and no user interaction (UI:N), so it can be fully automated.

4. The SpEL engine processes the expression, enters an algorithmically expensive computation path, and consumes excessive CPU, memory, or both. The application degrades or becomes completely unavailable.

A single HTTP request containing the crafted SpEL expression is enough, which makes the attack suitable for mass scanning and automated exploitation campaigns.

Comparison with prior SpEL DoS vulnerabilities

The three SpEL DoS CVEs point to a persistent architectural weakness:

Each new CVE shows that incremental patches have not adequately bounded the SpEL engine's resource consumption. The jump to 7.5 suggests that point fixes alone are insufficient, and that the SpEL engine may require architectural hardening, such as mandatory resource limits or sandboxed evaluation contexts for untrusted input.

Mitigation

The official Spring advisory prescribes one mitigation: upgrade to the corresponding fixed version. After upgrading, the advisory says, "No further mitigation steps are necessary." There are no documented workarounds for CVE-2026-41850.

For open-source users:

• Upgrade Spring Framework 7.0.x to 7.0.8
• Upgrade Spring Framework 6.2.x to 6.2.19

For commercial and enterprise users (via Tanzu Spring Enterprise):

• Apply patch 7.0.7.1 for 7.0.x deployments
• Apply patch 6.2.18.1 for 6.2.x deployments
• Apply patch 6.1.28 for 6.1.x deployments
• Apply patch 5.3.49 for 5.3.x deployments

Broadcom provides Day 0 access to validated CVE patch releases through the Tanzu Spring Enterprise Repository. The repository isolates security fixes from other changes and offers software supply chain builds validated to SLSA level 3, covering the full transitive dependency graph.

For Maven-based projects, the upgrade looks like this:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-framework-bom</artifactId>
            <version>7.0.8</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

A note on historical workarounds: The advisory for the prior CVE-2024-38808 recommended evaluating user-supplied expressions using a SimpleEvaluationContext in read-only mode, which strictly limits the capabilities available to the SpEL engine. Organizations that cannot upgrade immediately may consider this approach to reduce risk, but the official advisory does not confirm that it works against CVE-2026-41850 specifically.

MITRE's general mitigation best practices for CWE-407 include:

• Using constant-time or logarithmic operations to process untrusted data
• Imposing strict size and recursion limits on expression evaluation
• Conducting formal complexity analyses during code review
• Rate-limiting expression evaluation requests from untrusted sources

Affected systems and versions

CVE-2026-41850 affects four major Spring Framework version branches:

The advisory also states that "Versions that are no longer supported are also affected." Organizations on the 6.1.x and 5.3.x branches cannot get open-source patches. They must either migrate to a supported branch or get commercial patches through Broadcom's Tanzu Spring Enterprise offering.

Any application that evaluates user-supplied SpEL expressions is vulnerable, regardless of the deployment model. The vulnerability is exploitable over any network path without authentication.

Vendor security history

Spring Framework has had a steady run of security vulnerabilities, particularly in its web stack and expression evaluation components. Several CVEs have been disclosed in 2026 alone:

The Spring advisory for April 2026 described "3 Web Stack DoS and Cache Poisoning CVEs" in a single batch. Broadcom reported a 1700% increase in monthly security advisories from March to April 2026, and attributes the surge in part to AI-assisted vulnerability discovery by both researchers and its own engineering team.

Broadcom has responded with several initiatives: AI-assisted security analysis using scanning based on frontier models, Project Glasswing (an Anthropic-based LLM initiative for proactive defense), and SLSA Level 3 supply chain validation through the Tanzu Spring Enterprise Repository. Purnima Padmanabhan, VP and GM of Broadcom's Tanzu Division, said that Broadcom's position as "steward and sole committer" means the company can "better secure it at the source for everyone who depends on it."

The wider Spring ecosystem has also seen significant security research in 2026. One example is CVE-2026-40478, a critical Thymeleaf sandbox bypass discovered by Endor Labs that allows arbitrary code execution in Spring applications. It shows that expression-based vulnerabilities in the Spring ecosystem can escalate beyond DoS to remote code execution.

The researcher credited with discovering and reporting CVE-2026-41850 is @wo1enca1ca1.

References

• CVE-2026-41850: Spring Framework Algorithmic Denial of Service (Official Advisory)
• CVE-2026-41850 on Vulners
• Spring Framework 7.0.8 and 6.2.19 Available Now
• Broadcom Expands Its Investment in Spring and Java Ecosystem Security
• Broadcom Injects Security Updates into Spring, Java Ecosystems (SDxCentral)
• Broadcom Aims to Better Secure Spring Applications in the AI Era (DevOps.com)
• CWE-407: Inefficient Algorithmic Complexity (MITRE)
• CVE-2024-38808: Spring Expression DoS Vulnerability (Prior SpEL DoS)
• Expression DoS Vulnerability Found in Spring: CVE-2023-20861 (Code Intelligence)
• Spring Framework Vulnerable to Denial of Service (GitLab Advisory for CVE-2024-38808)
• Algorithmic Complexity Vulnerabilities: An Introduction (Two Six Technologies)
• Spring Framework April 2026: 3 Web Stack DoS and Cache Poisoning CVEs (HeroDevs)
• CISA Known Exploited Vulnerabilities Catalog
• Thymeleaf Sandbox Bypass CVE-2026-40478 (Endor Labs)