Python applications evaluate attacker-reachable expressions in two very different places, and the two behave nothing alike once input arrives. The language's own eval and exec compile and run arbitrary Python, so any input that reaches them is a direct path to code execution on the host. Embedded policy languages such as Common Expression Language are deliberately not Python: they are sandboxed evaluators used for admission control, authorization, and validation, so the same injection mindset produces logic and policy manipulation rather than a shell.
Read both pages together, because the practical mistake is treating one like the other. An expression sink that runs real Python is scored as remote code execution; a CEL expression that an operator believed was "just a filter" is scored as a policy or authorization bypass, not RCE.
- eval() and exec() covers genuine arbitrary code execution through the interpreter, builtins abuse, the class-traversal gadget walk that survives restricted builtins, and why
ast.literal_evalis the safe sibling. - Common Expression Language covers the sandboxed case: manipulating authorization and admission decisions, disclosing context exposed to the expression, and abusing any dangerous host-registered functions.