Improper Neutralization of Special Elements used in an Expression Language Statement
Expression Language EL is a templating mechanism used in Java web frameworks and other platforms to dynamically evaluate expressions within templates. When…
Expression Language (EL) is a templating mechanism used in Java web frameworks and other platforms to dynamically evaluate expressions within templates. When user input is directly embedded into EL statements without proper sanitization, attackers can inject malicious expressions that alter application logic or execute arbitrary code. This weakness is particularly dangerous because EL interpreters often have access to application objects and methods, making code execution a realistic outcome.
02How It Happens
Expression Language statements use special syntax (like ${} or #{} depending on the framework) to evaluate expressions at runtime. When an application constructs these statements by concatenating user-supplied data—such as form parameters, URL query strings, or database values—without escaping or validating that input, an attacker can inject EL metacharacters and operators. The EL interpreter then parses and executes the injected expression as legitimate code, potentially accessing sensitive objects, calling methods, or manipulating application state. This is fundamentally different from simple string injection because EL has its own evaluation engine with access to the application's object model.
03Real-World Impact
Successful EL injection can lead to arbitrary code execution, allowing an attacker to read sensitive files, modify application data, create backdoor accounts, or pivot to other systems. Even if full code execution is not achieved, attackers can often access application objects to extract configuration data, session tokens, or database credentials. The severity depends on what objects and methods the EL engine can reach, but in typical Java web applications, the impact is severe.
Why it's vulnerable: If the templating engine supports expression evaluation (as Jinja2 does), an attacker can inject template syntax like {{ 7 * 7 }} or {{ config }} into the name parameter, causing the engine to evaluate arbitrary expressions rather than treating the input as plain text.
Why it's vulnerable: Using eval() with user input allows arbitrary PHP code execution. Even without eval(), some templating systems that process user input as template code can be exploited to access object properties or call methods.
Never concatenate user input directly into template or expression strings. Always use parameterized template variables or placeholders.
Disable dangerous EL features if your framework allows it (e.g., disable method invocation or static method access in EL configuration).
Use allowlisting for dynamic template names or paths. If you must construct template identifiers from user input, validate against a whitelist of safe values.
Escape or encode user input appropriately for the output context (HTML, JavaScript, URL) before rendering, even if it's not in an EL expression.
Apply the principle of least privilege to the objects and methods exposed to the template engine; restrict access to sensitive application objects.
Use a sandboxed or restricted templating engine if your framework offers one, rather than a full-featured expression language.
06Signs You May Already Be Affected
Look for unexpected template or expression syntax in application logs, error messages containing ${...} or similar patterns in user-controlled fields, or unusual method calls in server logs that don't correspond to normal user actions. If you find template files or configuration that dynamically construct EL statements from request parameters, that is a strong indicator of this vulnerability.
