How should security teams prevent code injection in formula evaluation features that use recursive placeholder substitution?

Why recursive placeholder substitution turns formula features into an injection boundary

Formula engines are often treated as safer than general-purpose code execution because they accept only a constrained syntax. Recursive placeholder substitution changes that assumption. Each substitution step can transform a benign-looking expression into a different structure, so the security boundary is not the user input alone, but the final evaluated form after all expansion is complete.

That distinction matters because validation performed too early can be bypassed by structure changes introduced later. A placeholder may expand into operators, function names, delimiters, or nested expressions that were not present in the original string. Even if the feature is marketed as “formula only,” recursive expansion can still create the same practical risk class as OWASP Top 10 style injection flaws when the parser or evaluator is fed attacker-influenced structure.

What secure validation needs to inspect after every transformation

Security teams should validate the exact string or abstract syntax tree that will actually be executed, not the partially substituted intermediate state. If the engine normalises, resolves, or re-expands placeholders multiple times, each stage becomes part of the attack surface and should be checked for syntax changes, forbidden tokens, unexpected nesting, and length or complexity growth that can indicate abuse.

Safer designs reduce the problem space by avoiding eval-style evaluation entirely, using a purpose-built expression parser with an allowlist of operators and functions, and rejecting any placeholder grammar that can reintroduce control characters. Where recursive substitution cannot be removed, the implementation should be deterministic, bounded, and revalidated after each pass so that structure-changing payloads do not survive to the final execution step.

How attackers abuse recursive substitution to smuggle executable structure

The core abuse pattern is simple: the attacker supplies input that looks harmless before substitution, but becomes dangerous after one or more placeholder expansions. That can enable hidden function calls, altered precedence, delimiter breakout, or unexpected references to privileged data sources. In practice, the weakness is often not the substitution mechanism itself, but the trust placed in an earlier validation checkpoint that no longer reflects the final expression.

This is especially risky when formula features are used for templating, reporting, workflow logic, or user-configurable business rules, because those use cases invite dynamic input and repeated transformation. Teams should assume that any attacker-controlled placeholder can be used to reshape the parse tree, not merely the literal characters of the initial string. That is why formula safety must be assessed at the point of execution, and why recursive expansion should be treated as a code transformation step, not a formatting convenience.

Risk and Threat Considerations

Recursive placeholder substitution creates an injection path that can hide malicious structure until the final evaluation pass. The danger is not limited to arbitrary code execution, it also includes business-logic abuse, data exposure, and unexpected access to internal functions if the evaluator exposes them.

Failure mechanism: An attacker places payload fragments across one or more placeholders so the dangerous tokens only appear after substitution, bypassing checks that ran on the original text or on an incomplete intermediate form.

Impact: The result can be unauthorized formula execution, sensitive data disclosure, integrity loss in generated outputs, or downstream application compromise if the evaluator can invoke powerful functions or reach external resources.

Practitioner Guidance

What to verify: Verify that the control checks the final executable expression, not just the user-supplied template or the first expansion result. If the system allows recursive expansion, confirm that every pass is bounded and that no new operators, function names, or delimiters can appear after a safety decision has already been made.

Common mistake: The usual error is to validate once, then trust every later transformation as if it were harmless string processing. In formula features, transformation is the attack path, so any change that can alter parse structure should force a fresh evaluation of safety.

Practitioner takeaway: Treat recursive substitution as a parsing and authorization problem, not a text-cleanup problem, and never let an earlier validation result stand after the expression has changed.

Related resources from NHI Mgmt Group

• How should security teams prevent code injection in modern applications?
• How should security teams prevent Python code injection when applications need dynamic behavior?
• How should security teams use prompt rules to prevent insecure code from being generated in AI-assisted development?
• How should security teams prevent command injection when an API needs to use a file name or system command on the server side?