Attackers use an eval function to execute injected code or expressions if the input reaches it unsafely. That can turn data into executable logic, leading to code execution, data theft or configuration changes. Avoid eval for untrusted input, use fixed parsing or mapping instead, and constrain any dynamic evaluation to tightly controlled, validated data.
How eval becomes an execution primitive
Attackers do not need eval to be inherently malicious. They need a path where untrusted input reaches it, because then strings can be interpreted as code instead of data. That turns a parsing shortcut into an execution primitive, which is why the same pattern can lead to command execution, data exposure, or configuration tampering depending on what the evaluated expression can touch.
The core failure is boundary collapse: application data crosses into the interpreter without strict validation, a fixed grammar, or a narrow allowlist. Once that happens, the attack is often less about the function name and more about where the input came from, what globals or helpers are exposed, and whether the expression can reach file, network, database, or system APIs.
Safe alternatives usually depend on the real need. If the task is selection, use a mapping or lookup table. If it is parsing, use a parser for a fixed grammar. If some dynamic behavior is unavoidable, constrain the input to a small validated domain and keep the callable surface as narrow as possible.
Where attackers get leverage from unsafe evaluation
Unsafe evaluation is attractive because it can compress multiple actions into one payload, especially when the code path already has useful privileges. A successful injection may read sensitive values, alter program state, or pivot into broader execution paths, and the resulting impact depends on the permissions of the process that performs the evaluation.
Attackers also like eval-style bugs because they often hide in “flexible” features such as rule engines, expression filters, template helpers, ad hoc calculators, and import or dispatch logic. Those features are commonly added for convenience, then later reused in security-sensitive paths where the original trust assumptions no longer hold.
For defenders, the important question is not whether an input field “looks dangerous”, but whether it can influence interpreter behavior at all. If the answer is yes, the issue should be treated as code execution risk first and a simple input-validation bug second. That framing is especially important when the evaluated content can read configuration, reach secrets, or invoke helper functions.
Why removal is usually better than hardening eval
In practice, hardening eval is fragile because every additional capability expands the attack surface. The more syntax, globals, or helper objects you expose, the harder it becomes to prove that the evaluated expression cannot escape its intended sandbox. A small mistake in quoting, escaping, or normalization can reintroduce the original flaw.
The more reliable pattern is to replace dynamic evaluation with explicit logic. Use named operations, switch-style dispatch, declarative rules, or a purpose-built parser that only accepts the expressions the application truly needs. If you must support user-defined formulas or conditions, isolate them from the main runtime and treat the accepted language as a formally limited interface.
When code review finds eval, the next step is to trace its inputs and privileges, not just to search for obvious bad characters. The practical review question is whether an attacker can shape executable behavior, not whether the function appears in a narrow or supposedly internal code path.
Risk and Threat Considerations
Unsafe eval is risky because it can convert a low-friction input bug into direct code execution, data theft, or unauthorized configuration change. The impact is often determined by the process context, so even a “small” injection can become serious if the evaluated code runs with access to secrets, service credentials, or privileged administration paths.
Failure mechanism: An attacker supplies text that is interpreted as executable logic, then uses the interpreter’s own privileges and reachable helpers to read data, change state, or chain into broader system access.
Impact: The result can range from single-request data exposure to full application compromise, with blast radius expanding if the evaluated path can touch filesystem, network, database, or deployment controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Unsafe eval enables script or command-style execution from attacker input. |
| Recommendation — Map eval abuse to T1059 and hunt for injected interpreter execution paths. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Replacing eval with safer parsing is a secure coding and application hardening concern. |
| Recommendation — Remove eval from untrusted paths and use fixed parsing or allowlisted dispatch instead. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Eval misuse is an architecture and secure-coding flaw that turns data into executable logic. |
| Recommendation — Design out dynamic evaluation and constrain any necessary expression handling to a fixed grammar. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The risk begins when attacker-controlled input reaches executable evaluation. |
| SA-11 — Developer Testing and Evaluation | Testing should confirm eval-like paths cannot be reached with untrusted input. | |
| Recommendation — Validate and constrain input before it can influence executable behavior. Test for code-injection paths wherever input is converted into executable logic. | ||
Practitioner Guidance
What to verify: Trace every eval-like call to its exact data source and execution context. If any untrusted or user-influenced input can reach it, treat the path as a priority remediation item even when the function is wrapped in helper code or appears limited to “internal” use.
Decision rule: If the intended behavior can be expressed as fixed parsing, mapping, or rule selection, remove eval entirely. Keep dynamic evaluation only when there is a clear business need, a tightly defined language, and a minimal execution surface.
Practitioner takeaway: The real control is not “sanitise eval better”, it is to stop treating attacker-controlled text as code unless the evaluated language is deliberately tiny, fully constrained, and isolated.
Related resources from NHI Mgmt Group
- Guide: MITRE D3FEND Guide
- How do attackers turn a supply-chain incident into wider NHI compromise?
- How do attackers operationalise stolen OAuth tokens at scale?
- Why do attackers often check model availability before trying to generate content?
- How do attackers turn stolen npm secrets into broader compromise?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org