CWE-917 Expression Language Injection

Coverage: 5 rules in the SiteShadow rule registry target this CWE (registry v2.0.0). Regex 5 Also: Taint and heuristic analyzers may also detect related flows (see coverage for the authoritative list) Registry tagging shows intent, for sample-level behaviour and benchmarked gaps see known gaps.

What this means

SiteShadow flagged an "expression language" (EL) evaluation where untrusted input can influence the expression being executed. ELs show up in templating systems, rules engines, query DSLs, and "formula" features.

Why it matters

Expression injection can execute code or access sensitive data.

• Data exposure: expressions can access internal objects/fields you didn't intend to expose.
• Authorization bypass if expressions decide access or compute roles.
• Code execution in some stacks when ELs allow method invocation / reflection.

Safer examples

1) Don't evaluate user-provided expressions

Accept data (JSON) and interpret it yourself, rather than executing a mini-language.

2) If you must support "formulas", allowlist operations

Only allow a small set of operators/functions and reject everything else.

allowed = {"add", "sub", "mul", "div"}
if op not in allowed:
    raise ValueError("Unsupported operation")

3) Sandbox and remove dangerous capabilities

Disable method calls, reflection, filesystem/network access, and limit CPU/timeouts. (Still risky; prefer eliminating EL evaluation.)

How SiteShadow detects it (high level)

• Detects EL/template evaluation entry points and tracks whether the evaluated expression is influenced by untrusted input.
• Flags cases where evaluation results control permissions, data access, or execution.

References

• CWE-917: https://cwe.mitre.org/data/definitions/917.html

---

← Back to Vulnerability Library