Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')

Incomplete Base
Structure: Simple
Description

Expression Language Injection occurs when an application uses untrusted, external input to build an expression language statement—common in frameworks like Java Server Pages (JSP)—without properly sanitizing it. This allows an attacker to inject malicious expressions that alter the intended logic and execute arbitrary code when the statement is processed.

Extended Description

Frameworks like JSP allow developers to embed dynamic expressions directly into web pages. If these expression evaluation features are left enabled and user input flows into them without validation, attackers can craft inputs that break out of the intended data context. The injected expressions are then executed on the server, potentially leading to data exposure, system compromise, or other unexpected behavior. Preventing this requires disabling expression evaluation where it's not needed, rigorously validating and sanitizing all user inputs that touch expression contexts, and adopting a secure coding policy for the framework. Managing this at scale across a large codebase is difficult; an ASPM like Plexicus can help you track and remediate these flaws across your entire stack. While SAST tools catch the vulnerable pattern, Plexicus uses AI to suggest the actual code fix, saving hours of manual security work.

Common Consequences 2
Scope: Confidentiality

Impact: Read Application Data

Scope: Integrity

Impact: Execute Unauthorized Code or Commands

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 3
Phase: Architecture and Design
Avoid adding user-controlled data into an expression interpreter when possible.
Phase: Implementation
If user-controlled data must be added to an expression interpreter, one or more of the following should be performed: - Validate that the user input will not evaluate as an expression - Encode the user input in a way that ensures it is not evaluated as an expression
Phase: System ConfigurationOperation
The framework or tooling might allow the developer to disable or deactivate the processing of EL expressions, such as setting the isELIgnored attribute for a JSP page to "true".
Observed Examples 1
CVE-2021-44228Product does not neutralize ${xyz} style expressions, allowing remote code execution. (log4shell vulnerability in log4j)
References 4
Expression Language Injection
Stefano Di Paola and Arshan Dabirsiaghi
12-09-2011
ID: REF-911
Remote Code with Expression Language Injection
Dan Amodio
14-12-2012
ID: REF-912
Neutralizing Your Inputs: A Log4Shell Weakness Story
CWE/CAPEC
ID: REF-1279
Applicable Platforms
Languages:
Java : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Alternate Terms

EL Injection

Notes
RelationshipIn certain versions of Spring 3.0.5 and earlier, there was a vulnerability (CVE-2011-2730) in which Expression Language tags would be evaluated twice, which effectively exposed any application to EL injection. However, even for later versions, this weakness is still possible depending on configuration.