The trust boundary breaks because the application stops interpreting data and starts generating executable code inside the runtime. If attacker-controlled expressions or variables reach a compiler such as new Function(), the result is not just a bad calculation. It is code execution with the privileges of the host process, which can expose secrets, local files, and network reachability.
What breaks when a formula compiler turns data into executable JavaScript?
The trust boundary breaks because the system stops treating the expression as inert input and starts treating it as code. Once attacker-controlled text reaches a compiler such as new Function(), the question is no longer whether the formula is valid, but whether the generated JavaScript can execute with the host application’s privileges.
Why the failure is more serious than a bad calculation
A normal formula engine should evaluate constrained expressions inside a narrow grammar. A JavaScript compiler collapses that boundary, so the same input can move from arithmetic into control flow, object access, and function invocation. That changes the failure mode from incorrect output to runtime code execution, which can expose secrets, read local files, make outbound requests, or tamper with application state.
In practice, the dangerous part is not just syntax injection. The runtime now inherits the host process environment, module access, network reachability, and any privileged configuration loaded into memory. Even if the formula was meant to be “just math,” compiling it as JavaScript gives the attacker a much richer execution surface than the product owner intended.
Where the attack path usually opens
The path is usually simple: user input, template data, or a field that was assumed to be harmless reaches a dynamic code constructor, then executes in-process. Once that happens, the attacker can often pivot from expression control to data exposure or command-like behavior through the JavaScript runtime itself.
This is why dynamic compilation is especially risky in systems that process untrusted workflows, rule engines, customization fields, or browser-side business logic. The original design may have intended flexibility, but if the implementation cannot strictly separate data from code, the trust model is broken at the point of compilation.
One practical warning sign is any code path that builds source text and then evaluates it indirectly. Security teams should treat that pattern as a code-generation boundary, not as a harmless convenience layer. When formulas are user-controlled, the safe assumption is that the attacker is trying to reach executable context, not merely trigger an invalid calculation.
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 OWASP ASVS, NIST SP 800-53 Rev 5 and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Dynamic code generation is a secure-architecture failure mode for untrusted input. |
| Recommendation — Eliminate runtime code construction for user-controlled formulas and use a constrained evaluator instead. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted formulas need strict validation before they can influence executable logic. |
| SI-7 — Software, Firmware, and Information Integrity | Generated code must not be allowed to undermine runtime integrity or trust boundaries. | |
| Recommendation — Validate and constrain formula input before any parsing or execution step. Prevent untrusted text from being promoted into executable application logic. | ||
| OWASP SAMM | SSM — Software Security Management | Secure SDLC practices are needed to stop code-generation anti-patterns from reaching production. |
| Recommendation — Review dynamic-evaluation patterns during design and threat modeling before release. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Compiling attacker-controlled input into JavaScript aligns with scripting-interpreter abuse. |
| Recommendation — Monitor for code paths that turn untrusted input into runtime script execution. | ||
Practitioner Guidance
What to verify: Confirm whether the formula language is actually a restricted expression parser or just JavaScript generation with a friendlier wrapper. If the latter, treat every untrusted field that reaches it as code injection exposure.
Decision rule: If a user can influence tokens that become part of generated source, replace compilation with a non-Turing-complete evaluator or a strict AST-based whitelist. Do not “sanitize” your way out of a code generator that was never safe for untrusted input.
What practitioners underestimate: The impact is not limited to the formula feature itself. Any in-process code execution inherits the application’s secrets, credentials, filesystem reach, and internal network access, so blast radius depends on the host runtime, not the formula syntax.
Practitioner takeaway: The key control is preserving the data/code boundary. If that boundary is gone, the right question is no longer whether the formula is correct, but whether the generated code can be executed at all.
Related resources from NHI Mgmt Group
- What breaks when untrusted formulas reach toJSFunction() in Node.js apps?
- What breaks when Android PAC processing loads untrusted JavaScript in a long-lived system service?
- What breaks when spreadsheet formulas can reach host execution?
- What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?