SpEL Injection

Expanded Definition

SpEL injection is a server-side code execution flaw that emerges when Spring Expression Language is evaluated on input that was never meant to be treated as executable logic. Unlike a simple template mistake, the issue appears when application code passes user-supplied strings into expression evaluators, allowing attackers to reference properties, invoke methods, or traverse object graphs. In Spring-based applications, the risk is highest when developers use dynamic expression parsing for filtering, routing, authorization, or object binding without strict input separation.

The security concern is not Spring itself, but the unsafe mixing of data and code. A benign-looking field, such as a username, filter value, or JSON property, can become executable if it is concatenated into an expression and then evaluated. That makes SpEL injection closely related to other expression-language injection classes, but the impact can be broader because Spring expressions often have access to application objects and framework services. Guidance across vendors is consistent on the core issue, though implementation details vary by context and Spring version. For a broader governance lens, the NIST Cybersecurity Framework 2.0 frames this as an application security and secure coding control problem.

The most common misapplication is treating SpEL as a harmless formatting tool, which occurs when developers interpolate attacker-controlled values into expressions during request handling.

Examples and Use Cases

Implementing SpEL usage rigorously often introduces developer friction, requiring organisations to weigh flexible dynamic behaviour against the cost of stricter input handling and reduced runtime convenience.

• An application builds a dynamic authorization rule from request parameters, and the expression engine evaluates attacker-controlled syntax instead of a fixed policy.
• A search or filter feature accepts a field name and operator, then assembles a SpEL string that can be altered to reach unexpected object methods.
• Security tooling or admin consoles use expressions for automation, but insufficient validation lets a low-privilege user inject logic into an ostensibly read-only workflow.
• Object mapping code evaluates expressions against domain objects, and malformed input exposes getters, setters, or nested properties that were never intended for external control.
• Teams using Spring for application logic should treat expression parsing with the same caution described in secure coding guidance from Spring Security guidance and the OWASP Top 10, because the attack path often starts as data handling rather than obvious code execution.

Why It Matters for Security Teams

SpEL injection matters because it collapses the boundary between input validation and execution. Once an attacker controls expression content, they may pivot from data exposure to method invocation, privilege abuse, or full compromise of the affected service. For security teams, the issue is often missed during design reviews because the code appears to be “only formatting” or “only filtering,” yet the evaluator can still execute logic with application privileges.

From a governance perspective, this is an application-layer prevention problem that belongs in secure development, code review, and runtime testing. The right response is to avoid evaluating untrusted input, use allowlists for any dynamic expression elements, and prefer fixed logic over string-built expressions. Where expressions are unavoidable, teams should constrain the evaluation context and test for injection paths as part of release assurance. NIST guidance on secure software practice and the broader control model in the NIST Cybersecurity Framework 2.0 both support this risk reduction approach.

Organisations typically encounter the operational reality of SpEL injection only after an abuse case, at which point expression review becomes an unavoidable incident-response and remediation task.

Related resources from NHI Mgmt Group

• What is credential injection risk and how does it occur?
• What is the difference between prompt injection risk and identity abuse in agents?
• What is the difference between prompt injection and credential theft for agents
• What is the difference between prompt injection and tool poisoning?