A pattern where text is interpreted as executable code while the application is running. It increases risk because any failure in upstream validation can become immediate execution, which is why safer designs use structured parsing and explicit action handling instead.
What Runtime Code Evaluation Means
Runtime code evaluation is the moment a system treats text as executable instructions while it is already running. That makes the boundary between data and code fragile, because a single validation failure can turn an input string into immediate behaviour change. Safer designs keep input in structured form and map it to explicit actions rather than interpretation.
The core idea is not limited to any one language or platform. It can appear in template engines, scripting features, expression evaluators, rule systems, plugin loaders, or dynamic content handlers. The security question is always the same: can an attacker influence what is executed, or shape the instructions that will be executed later?
Why It Is Dangerous
The danger comes from collapsing parsing, decision-making, and execution into one step. Once untrusted text reaches an execution context, the application may run commands, expressions, or generated logic with the same authority as the application itself. That can convert a small input flaw into code execution, data exposure, or destructive state changes.
The risk is often highest where developers assume the input is “just configuration” or “just a pattern.” In practice, many runtime-evaluation flaws arise because the application trusts a string too early, then interprets it too broadly. The safer model is to treat text as data unless it is deliberately parsed into a limited and well-defined structure.
Common Failure Patterns
Most failures come from weak input handling, unsafe interpolation, permissive expression syntax, or hidden fallback paths that promote untrusted content into executable form. Dynamic features are especially risky when they accept multiple syntaxes, because a validation rule that is safe for one format may fail open for another.
Another common pattern is “partial trust,” where developers try to sanitize text but still allow enough special characters, operators, or function calls to alter behaviour. At that point, the control is no longer really preventing execution, only narrowing the attacker’s options. When the allowed surface is still expressive, the remaining risk can stay severe.
Runtime evaluation also complicates review and testing. Static code review may miss dangerous execution paths that only appear with certain input combinations, feature flags, or runtime data states. That is one reason structured parsing and explicit allowlisted actions are preferred over generic string evaluation.
Safer Design and Operational Controls
Defensive designs separate parsing from execution. A parser should convert input into a limited structure, and later logic should choose from known actions rather than interpret arbitrary text. This reduces the chance that a malformed or malicious string becomes live code.
Review every place where the application accepts text that can influence execution, including formulas, filters, expressions, templates, and embedded commands. The NIST SP 800-190 Container Security guidance is useful here because runtime risk often depends on how application components, images, and execution boundaries are controlled at deploy and runtime.
For organisations that need a broader control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls provides relevant control families for configuration management, system integrity, access control, and logging. These controls help reduce the chance that unsafe dynamic behaviour is introduced, hidden, or left undetected.
Detection and Review After Exposure
If runtime code evaluation has been used unsafely, defenders should assume that malicious input may already have reached an execution path. That makes post-exposure review important even when the issue has been corrected, because the initial execution may have created persistence, altered state, or exposed data before the fix landed.
Look for abnormal process creation, unexpected command strings, template or expression failures, new outbound connections, and application logs that show unusual evaluation inputs. A useful companion reference is MITRE ATT&CK Enterprise Matrix, which helps analysts map what happened after execution, such as privilege escalation, credential access, or lateral movement.
Where evaluation affects secrets, sessions, API keys, or service credentials, assume those materials may need rotation if compromise is plausible. Dynamic execution flaws are dangerous not only because code can run, but because the code often runs inside a trusted application context with access to sensitive material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Controls unsafe text handling before it reaches execution paths |
| CM-7 — Least Functionality | Limits unnecessary runtime features that expand executable surface area | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports review of suspicious evaluation events and execution traces | |
| Recommendation — Validate all untrusted input before it can influence executable logic. Disable dynamic features and code paths you do not explicitly need. Review logs for abnormal evaluation inputs and resulting execution behavior. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | Covers safe handling of untrusted text before interpretation or execution |
| V15 — Secure Coding and Architecture | Supports designs that avoid string-to-code execution patterns | |
| Recommendation — Treat user-controlled text as data and encode or sanitise it appropriately. Redesign dynamic features so inputs map to explicit actions rather than code. | ||
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 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org