A processing flaw where user-controlled content is interpreted more than once, often first as data and then as code. In workflow and template systems, double evaluation creates an execution boundary collapse because content that should remain inert can be re-read as instructions on a later pass.
How Double Evaluation Happens
Double evaluation occurs when a system reads the same user-supplied content more than once and, on a later pass, treats it as executable syntax instead of inert data. The flaw usually appears where parsers, renderers, expression engines, or templating layers are chained together without a strict boundary between input and code.
This is not limited to one technology stack. Any workflow that normalizes, transforms, or re-renders content can accidentally turn a safe string into active instructions if the second pass applies a different grammar or context than the first.
Why It Becomes Dangerous
The security problem is execution boundary collapse. Content that was meant to remain data can be reinterpreted as a template directive, expression, or command, which lets an attacker smuggle instructions through an earlier validation layer. In practice, the danger increases when different components disagree about whether a payload is literal text or structured input.
That mismatch is especially harmful in content pipelines that combine sanitization, encoding, and templating. A payload that survives the first layer can become dangerous after a later decode, expansion, or substitution step, which means the real trust decision is often made by the second parser rather than the first.
Common Places It Appears
Double evaluation shows up in template engines, workflow automation, configuration rendering, expression languages, and systems that repeatedly process markup or structured data. It is also common when one component escapes content for display, but another component later interprets the same content in a more privileged context.
It often hides inside convenience features, such as nested templating, variable expansion, macro substitution, or dynamic rule evaluation. The issue is not the feature itself, but the fact that the same bytes are allowed to cross from data handling into code handling without a clearly enforced boundary.
How to Recognise It and Why It Matters
A good indicator is any design where user input is intentionally or accidentally fed through two different interpreters, especially when the second interpreter has more authority than the first. The term matters because the vulnerable path is not always obvious in code review, and the dangerous behavior may only appear after transformations that look harmless in isolation.
Security teams should think in terms of parse stages, trust transitions, and context changes. When content can be re-read under a new grammar, the protection model has to account for the final evaluation point, not just the initial validation point.
Risk and Threat Considerations
Double evaluation is risky because a payload can look inert during initial inspection and still execute later when a downstream parser, renderer, or expression engine reprocesses it. That makes it a classic trust-boundary failure, especially in systems that chain multiple transformation steps.
Failure mechanism: an attacker crafts input that survives the first pass as data, then becomes active code after decoding, substitution, or templating on a later pass.
Impact: the result can include remote code execution, template injection, command injection, authorization bypass, data exposure, or malicious workflow control, depending on the second interpreter’s privileges.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | Double evaluation often defeats earlier encoding or sanitization by reinterpreting content later. |
| V15 — Secure Coding and Architecture | The flaw is a boundary design problem where parsing stages and trust transitions are not isolated. | |
| Recommendation — Apply V1 controls to keep user input in a single, non-executable context across all render paths. Design multi-stage processing so untrusted content cannot cross from data handling into code execution. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Double evaluation begins with untrusted input that later becomes dangerous after downstream interpretation. |
| SC-39 — Process Isolation | Separating parsing and execution contexts helps prevent content from crossing into a privileged interpreter. | |
| Recommendation — Validate input once and prevent later components from reinterpreting it as instructions. Isolate processing stages so untrusted data cannot be promoted into executable context. | ||
| CIS Controls v8 | 16 — Application Software Security | Application-layer parsing and templating flaws are a software security concern requiring safe design. |
| Recommendation — Review application flows for repeated parsing and remove any path that evaluates user content twice. | ||
Practitioner Guidance
Common misunderstanding: developers often assume that one sanitization or escaping step is enough. With double evaluation, the important question is whether any later stage can reinterpret the same content under a different grammar.
Practitioner note: treat every transformation as a potential reclassification event. Preserve data as data, avoid re-evaluating user-controlled content, and review multi-stage pipelines for any point where a safe string can become executable instructions.
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 October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org