Prompt InjectionAI SecurityOWASP LLM Top 10CVE-2025-53773

Prompt injection: the attack that became problem #1 for anyone who put an AI agent to work

The moment an AI agent gets access to a tool, a file, or a shell, prompt injection stops being a chatbot trick and becomes a path to command execution. A technical overview with one confirmed real-world case.

By Vorvex TeamPublished on August 14, 20264 min read

Prompt injection isn't new, the term has circulated since the first LLMs hit production. What changed is the size of the blast radius. As long as the model only replied with text, a hidden instruction inside a malicious prompt produced, at worst, an embarrassing response. Now that AI agents read email, open files, call APIs, and run commands on a user's behalf, that same hidden instruction becomes a real action: a command executed, data exfiltrated, a configuration changed without anyone knowingly approving it.

What prompt injection actually is

It's the technique of embedding an instruction inside content the model will process, so the model treats that instruction as a legitimate command from the operator. There are two main variants. In direct injection, the user themselves writes the malicious prompt, usually to bypass the model's safety filters (jailbreak). In indirect injection, the one that matters in agentic environments, the attacker plants the instruction in content the agent will read later, with no direct interaction: an issue comment, a web page, a file, the body of an email. The model has no reliable way to distinguish 'this is data I should process' from 'this is an instruction I should follow', because both arrive through the same channel: text.

Diagram comparing direct injection (user typing in chat) and indirect injection (hidden instruction in a document being read by the agent) — Direct injection comes from the user themselves; indirect injection comes from external content the agent processes without knowing it's compromised.

From conversation to command execution: the GitHub Copilot case

The most concrete 2025 example is CVE-2025-53773, published on August 12 and classified as command injection (CWE-77) in GitHub Copilot and Visual Studio. The National Vulnerability Database and the GitHub Security Advisory (GHSA-3m2x-p87c-pwv6) confirm a CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), affecting Visual Studio 2022 versions 17.14.0 through 17.14.11, fixed in 17.14.12. Worth noting: several outlets covering the story repeated a CVSS of 9.6, a number that doesn't match what official sources record, exactly the kind of error we avoid here.

The mechanism is what matters. Malicious content planted somewhere Copilot processes, such as a project file or an issue description, instructs the agent to edit the `.vscode/settings.json` configuration file and flip on the `chat.tools.autoApprove` option. With that flag active, Copilot starts running tools and commands without asking for explicit user confirmation, the so-called YOLO mode. From there, the next command the agent decides to run (on instruction from that same malicious content) executes locally with no barrier left. Prompt injection stops being about tricking the model and becomes about switching off the one control that was still standing: human confirmation.

Diagram with four numbered steps representing a prompt injection attack chain: malicious content, instruction absorbed by the agent, action taken with a privileged tool, data exported or command executed. — The typical exploitation chain: content carries a hidden instruction, the agent processes it as a command, a privileged tool executes it, data leaves or a command runs with no human review.

Not an isolated case, and not vendor-specific

In March 2026, CVE-2026-2256 documented an equivalent flaw in MS-Agent, ModelScope's agent framework: unsanitized prompt-derived input allows arbitrary operating system command execution, CVSS 3.1 of 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), affecting version v1.6.0rc1 and earlier, also classified as CWE-77. Two different vendors, two different agent architectures, the same root cause: a command derived from content that should have been treated as data, executed without sufficient sanitization. It's no coincidence that prompt injection has held the top spot in the OWASP Top 10 for LLM Applications since the list was created.

Architecture diagram showing untrusted external content flowing through an AI agent into privileged system, API, and file access — The same risk architecture repeats: external content comes in, the agent processes it, and the output carries privileged access, regardless of vendor.

Why it's hard to fix for good

The difficulty is structural, not a matter of a missing patch. An LLM receives system instructions, conversation context, and external content through the same text channel, with no reliable cryptographic or structural separation between 'this is a command' and 'this is data to process'. Keyword filters and intent classifiers help, but they're heuristics, not guarantees, and every generation of defense produces a new generation of obfuscation technique to get around it. What actually changes the risk isn't making the model perfect, it's limiting what an injected instruction can do even when it slips through unnoticed.

Diagram showing system instruction and external data arriving at the model through the same text channel, indistinguishable from each other — The structural problem: command and data arrive through the same text channel, with no reliable cryptographic or structural separation between them.

Defense in depth: what actually reduces the risk

Treat all external content (web pages, PRs, emails, files, third-party API responses) as untrusted data, never as instructions, including inside the agent's own system prompt
Run the agent's tools in an isolated sandbox, with no direct access to the host shell, sensitive file system, or unrestricted network
Require explicit human confirmation for high-risk actions (running commands, sending data out, changing configuration), with auto-approval off by default
Apply least privilege to the credentials and scopes granted to the agent, never reuse a broad-access token
Log and monitor every action the agent takes, with alerting for usage patterns outside the expected baseline
Bring the agent and its integrations into pentest scope, testing prompt injection the same way any other untrusted input surface gets tested

Diagram of concentric circles numbered 1 through 4 around a padlock, representing successive layers of defense against prompt injection. — Defense in depth: no single layer solves it, but each one reduces the damage if the one before it fails.

What this changes for anyone evaluating a pentest

An AI agent with access to a tool, a file, or an API is no longer a product team experiment, it's an attack surface with the same weight as an API or an internal network. If a company has already put a coding copilot, a support agent, or an LLM-driven automation into production, that integration needs to enter the scope of the next security assessment, not as an add-on, as a standard item.

← Back to blog