PHP eval is a function that executes a string as PHP code at runtime. Developers use it for dynamic behaviour, but if attacker-controlled input reaches it, it becomes a code execution path that can lead to remote compromise, data access, or command injection.
What makes PHP eval dangerous
PHP eval turns a text string into executable PHP at runtime, so its danger is not the function itself but the trust boundary it creates. When user input, request parameters, database content, or another untrusted source can influence the string, the application can cross from data handling into direct code execution.
That makes eval a high-impact sink in web applications. A small input-validation mistake can become arbitrary PHP execution, which may expose configuration, session state, secrets, file access, database credentials, or any application capability available to the runtime process.
Common abuse patterns and failure modes
The most serious failure mode is attacker-controlled code execution, but eval also amplifies smaller mistakes. Developers sometimes use it to build formulas, templates, or dynamic routing logic, then later add string concatenation or weak filtering around it. That pattern often creates injection paths that are hard to audit because the final executable code is assembled indirectly.
Eval is especially risky when it is used to interpret fragments of code from plugins, content fields, or administrative tooling. In those cases, the original design intent may be convenience or extensibility, but the operational effect is that application logic becomes data-driven in a way that is difficult to constrain safely.
PHP and WordPress Security Guide
How organisations reduce exposure
The safest approach is to avoid eval in production code whenever a structured parser, whitelist, expression engine, or explicit function can achieve the same result. Where eval already exists, teams should inventory every call site, trace the full data flow into it, and identify whether any part of the string can be influenced outside trusted developer control.
Exposure review should include internet-facing endpoints, administrative features, CMS extensions, import functions, and legacy code paths that may look harmless but can still reach runtime execution. A vendor advisory or patch note may help when eval appears inside a third-party component, but the core question is always whether untrusted data can shape the executable string.
When removal is not immediate, compensating controls should narrow the blast radius: strict input handling, least-privilege runtime accounts, hardened file permissions, and segmentation around the affected service. These controls do not make eval safe, but they can limit what an attacker can do after reaching the sink.
Detection, review, and secure replacement
Detection should focus on both source code and runtime behaviour. In code review, look for functions that evaluate strings, indirect construction of executable snippets, and chained transformations that hide the final payload. At runtime, unexpected PHP execution, web shells, anomalous file writes, new outbound connections, or changes in application behaviour after a request may indicate exploitation.
After patching or removing eval, teams should review for secondary compromise. If attackers gained code execution, rotate credentials, invalidate sessions, inspect uploaded files and cron jobs, and compare application artefacts against known-good baselines. The goal is not only to close the sink, but also to confirm that no persistence was established through the original execution path.
PHP Git server compromise 2021
When PHP eval should be retired
Why practitioners should care: eval is usually a design smell, not a convenience feature worth preserving. If a code path can be expressed with native language constructs, configuration, or a constrained expression parser, retiring eval usually reduces both security risk and maintenance burden.
Common misunderstanding: filtering a few dangerous characters does not make runtime code execution safe. Attackers often find alternate syntax, encoding tricks, or payload shapes that survive weak sanitisation and still change execution flow.
Practitioner takeaway: Treat every remaining eval call as a temporary liability, document why it exists, and plan to replace it with a bounded alternative that does not execute arbitrary PHP text.
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 NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Input Validation | Untrusted input reaching eval is an input-validation failure that can become code execution. |
| AC-6 — Least Privilege | Eval impact depends on the privileges of the runtime account that executes the injected code. | |
| Recommendation — Validate and constrain every value that can reach dynamic code evaluation. Run the affected service with the minimum privileges needed for its task. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Eval is an insecure architectural pattern that ASVS expects teams to avoid in secure design. |
| Recommendation — Replace runtime code execution with safer, bounded application logic. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | PHP eval is a scripting interpreter path that adversaries abuse to execute attacker-supplied code. |
| Recommendation — Map eval abuse to interpreter execution and hunt for follow-on actions after suspicious input. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application security controls directly address unsafe coding patterns such as dynamic code execution. |
| Recommendation — Remove unsafe dynamic execution patterns during secure development and review. | ||
Related resources from NHI Mgmt Group
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 November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org