What is Unexpected Code Execution?

Unexpected code execution occurs when an attacker exploits an agent that writes and runs code to escalate into remote code execution, local system misuse, or infrastructure compromise.

These attacks take advantage of the fact that an agent cannot reliably recognize when text contains executable instructions. This gives an attacker several options. Prompt injection can be used to get the model to generate a malicious command disguised as normal output. Tool misuse can route ordinary text into a shell or interpreter that runs it. Unsafe serialization can turn a text string back into a live object as soon as it is deserialized. Because this code is often generated in real time, it can bypass traditional security controls.

In July 2025, a Replit coding agent ran unreviewed destructive commands during an active code freeze, deleting a live production database. Separate 2025 research disclosed a cluster of remote code execution flaws in the Cursor editor, including a vulnerability nicknamed MCPoison, where an approved MCP server configuration could be silently swapped for a malicious command after the fact.

Why it is Dangerous

Unexpected execution allows attackers to turn a code-generation feature into system compromise:

• Production data loss when an agent runs unreviewed install or shell commands against its own live environment during an automated repair or coding task
• Direct system compromise through shell commands embedded in a prompt and disguised as an ordinary instruction
• Backdoored output when a code-generation agent hallucinates a patch that looks legitimate but carries hidden malicious logic
• Configuration hijack, where a trusted connection like an MCP server gets swapped for a malicious one after initial approval, without triggering a new warning

Typical Manifestations

Unexpected execution follows a handful of recurring patterns:

• Shell command invocation triggered by a prompt that reads as an ordinary file-processing instruction
• Unsafe eval() calls exposed inside an agent’s memory system, processing untrusted content without sanitization
• Unsafe object deserialization, where a malicious payload triggers execution once it reaches another component
• Dependency lockfile poisoning, where an agent regenerating a lockfile from unpinned specs pulls in a backdoored package version

This risk exists because code that an agent writes and runs in the same step can skip key security checkpoints.

Sandboxing Agent-generated Code

Code generated by agents should follow strict secure-execution practices.

• Apply the input validation and output encoding guidance from LLM05:2025 Improper Output Handling to sanitize agent-generated code before it runs
• Keep agents out of direct contact with production systems, and run vibe-coding workflows through pre-production checks, security evaluations, and adversarial unit tests
• Ban eval() in production agents and require safe interpreters with taint-tracking on generated code
• Never run agent-generated code as root, execute it in sandboxed containers with strict network limits, and restrict filesystem access to a dedicated working directory
• Isolate per-session environments with permission boundaries, apply least privilege, and separate code generation from execution with a validation gate in between
• Require human approval for elevated runs, and keep an allowlist for auto-execution under version control
• Run static scans before execution, enable runtime monitoring for prompt-injection patterns, and log every generation and execution for audit

An agent should never be allowed to write and run its own code without security controls in place.

< Back to Glossary of Terms