CVE-2026-47886 in Spring Framework
Summary
by MITRE • 08/27/2026
Applications that evaluate user-supplied Spring Expression Language (SpEL) expressions may be vulnerable to a Denial of Service (DoS) attack when the power operator (^) is used with a BigDecimal or BigInteger operand and a large exponent value. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19 Spring Framework 6.1.0 - 6.1.28 Spring Framework 6.0.0 - 6.0.30 Spring Framework 5.3.0 - 5.3.49 Spring Framework 5.2.25.RELEASE and earlier
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability described involves a Denial of Service condition within the Spring Expression Language evaluation engine, specifically affecting applications that process user-supplied SpEL expressions. This flaw is present in multiple versions of the Spring Framework, including ranges from 5.2.25.RELEASE and earlier through to version 7.0.8. The core issue arises when an attacker provides a maliciously crafted expression utilizing the power operator with operands involving BigDecimal or BigInteger types paired with excessively large exponent values. Unlike typical injection vulnerabilities that aim for code execution, this specific flaw targets resource exhaustion by forcing the application into computationally intensive operations that consume excessive CPU cycles and memory resources.
From a technical perspective, the Spring Expression Language parser does not adequately validate the magnitude of exponents when performing arithmetic operations on arbitrary-precision numbers. When such an expression is evaluated, the underlying mathematical algorithms attempt to compute results with extremely high precision or iterate through calculations proportional to the size of the exponent. This behavior leads to unbounded resource consumption. In a production environment where SpEL expressions are derived from user input without strict sanitization or complexity limits, this can be triggered remotely by an attacker sending a single HTTP request containing the malicious expression. The application thread handling this request becomes blocked in a long-running computation, effectively hanging and preventing it from serving legitimate requests.
The operational impact of this vulnerability is primarily a Denial of Service against the affected Spring-based applications. Because Java threads are often tied to specific tasks or connections in web containers like Tomcat or Jetty, a single malicious thread consuming significant CPU time can degrade performance for all other users sharing that server resources. In worst-case scenarios involving multi-threaded environments or container orchestration platforms, this could lead to cascading failures where the application becomes unresponsive entirely, requiring manual intervention such as restarting services or scaling up infrastructure temporarily to mitigate the impact. This represents a significant availability risk for systems relying on dynamic expression evaluation features provided by Spring Framework.
This vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, and more specifically relates to scenarios where input validation fails to restrict computational complexity. In terms of threat modeling frameworks such as MITRE ATT&CK, this behavior corresponds to techniques used in Denial of Service attacks, particularly those involving resource exhaustion through algorithmic complexity rather than volume-based flooding. It highlights the importance of implementing strict limits on expression evaluation depth and operand sizes within any system that processes dynamic expressions from untrusted sources.
To mitigate this risk, organizations should immediately upgrade their Spring Framework dependencies to versions outside the affected ranges, ensuring they are running patched releases where input validation for arithmetic operations has been strengthened. For applications unable to update immediately due to compatibility constraints, implementing a custom SpEL evaluation context with restricted capabilities can help. This includes disabling dangerous functions and setting strict limits on expression complexity or execution time using timeout mechanisms provided by the hosting environment. Additionally, deploying Web Application Firewalls that detect patterns indicative of excessive mathematical computation in query parameters may provide an additional layer of defense against exploitation attempts targeting this specific flaw.