Remote Code Execution via eval() and Dynamic Code Injection

How the attack works

An agent is given a tool or instruction set that builds a string of code at runtime and executes it with eval(), Function(), or a similar dynamic-execution primitive. If any part of that string comes from untrusted input — user messages, retrieved documents, tool output — an attacker can inject their own code into it. That injected code runs with the same privileges as the agent process, letting the attacker escape whatever sandbox or tool restrictions were supposed to contain it. From there they can pivot to child_process or other system calls to reach the host.

Netzilo detection

Why it matters

Successful exploitation gives an attacker code execution inside the agent's process, which can lead to full compromise of the host running the agent, theft of credentials or data the agent can access, and disruption of any other agents or tools sharing that runtime.

What you can do

• →Audit agent tool code for eval(), Function(), vm.runInNewContext(), or equivalent dynamic execution calls and remove them where possible.
• →If dynamic code execution is unavoidable, never build the executed string from unsanitized user input, retrieved content, or other tool outputs.
• →Run agent tools in a properly isolated sandbox (separate process, restricted permissions, no filesystem or network access) rather than relying on in-process checks.
• →Review any matches against known false positives — documentation, code scanners, and tutorials that merely mention eval() — before treating them as incidents.

Known benign look-alikes

• Security documentation describing eval injection risks
• Code review tools that scan for eval usage
• Educational coding tutorials that include inline code snippets demonstrating eval() usage in a teaching context
• Automated code review reports that quote flagged source lines containing eval() or require('child_process') verbatim

References

• https://agentthreatrule.org/en/rules/ATR-2026-00110

Related threats