PaperlayerView exact revision on arXiv

Source-linked AI summary

Takedown: How It's Done in Modern Coding Agent Exploits

Eunkyu Lee, Donghyeon Kim, Wonyoung Kim, Insu Yun

arXiv:2509.24240v1cs.CR

TL;DR

Prior coding-agent security analyses were often fragmented or ad hoc, despite agents’ access to powerful tools and autonomous workflows. This paper systematically examines eight agents’ workflows and components, identifying 15 security issues. Chaining these issues enabled command execution in five agents and global data exfiltration in four, without user interaction or approval.

  • Problem

    Prior studies often focused on isolated threats or specific attack scenarios, leaving comprehensive analysis of coding-agent workflows and component interactions limited.

    Source: §I · p. 1

  • Method

    The authors systematically analyze eight coding agents by examining their internal workflows and security threats across components.

    Source: §I · pp. 1–2

  • Results

    The analysis identified 15 issues and demonstrated arbitrary command execution in five agents and global data exfiltration in four, without user interaction or approval.

    Source: §I · p. 2

  • Takeaways & Limitations

    The findings support comprehensive security analysis of LLM-driven agents because insufficient security considerations can lead to severe vulnerabilities.

    Source: §XV · p. 13

    The analysis focuses on coding agents; extending similar analysis to other LLM agents is challenging because their capabilities and threat models vary.

    Source: B. Non-coding Agents · p. 13

Abstract

from arXiv · show

Coding agents, which are LLM-driven agents specialized in software development, have become increasingly prevalent in modern programming environments. Unlike traditional AI coding assistants, which offer simple code completion and suggestions, modern coding agents tackle more complex tasks with greater autonomy, such as generating entire programs from natural language instructions. To enable such capabilities, modern coding agents incorporate extensive functionalities, which in turn raise significant concerns over their security and privacy. Despite their growing adoption, systematic and in-depth security analysis of these agents has largely been overlooked. In this paper, we present a comprehensive security analysis of eight real-world coding agents. Our analysis addresses the limitations of prior approaches, which were often fragmented and ad hoc, by systematically examining the internal workflows of coding agents and identifying security threats across their components. Through the analysis, we identify 15 security issues, including previously overlooked or missed issues, that can be abused to compromise the confidentiality and integrity of user systems. Furthermore, we show that these security issues are not merely individual vulnerabilities, but can collectively lead to end-to-end exploitations. By leveraging these security issues, we successfully achieved arbitrary command execution in five agents and global data exfiltration in four agents, all without any user interaction or approval. Our findings highlight the need for a comprehensive security analysis in modern LLM-driven agents and demonstrate how insufficient security considerations can lead to severe vulnerabilities.

I. INTRODUCTION

The study examines security across coding agents’ workflows and components, finding that component-level issues can combine into end-to-end attacks. Coding agents’ autonomous operation and powerful tools make these risks consequential.

A. Coding Agents

  • Coding agents can carry out complex programming tasks from high-level natural-language instructions with minimal human intervention.They differ from conventional coding assistants that provide autocompletion or comment generation.Source: §I · p. 1, A. Coding Agents · p. 2
  • File and terminal tools let agents access source files and execute shell commands, while MCP can add task-specific external tools.Agents often use approval mechanisms before potentially dangerous actions, such as executing a destructive command.Source: §I · p. 1, A. Coding Agents · p. 2

I. INTRODUCTION

  • An attacker can exploit an agent’s local-file access and web-connected tools to exfiltrate sensitive data through a malicious Git issue, without approval.The paper cites a Cursor vulnerability as an example of this risk.Source: §I · p. 1
  • Prior analyses were often fragmented or ad hoc, leaving system-wide attack chains and security-critical components underexamined.Examples of overlooked components include approval mechanisms, file operations, and terminal operations.Source: §I · p. 1
  • The issues enabled arbitrary command execution in five agents and global data exfiltration in four, without user interaction or approval.The attacks compromise system integrity and confidentiality.Source: §I · p. 2
  • The study systematically analyzes eight coding agents’ workflows and component-level threats, identifying 15 issues, including previously overlooked ones.The issues mainly stem from inadequate security policies or implementation bugs.Source: §I · pp. 1–2

B. Prompt Injection Attacks

The paper distinguishes direct from indirect prompt injection and specifies the adversary assumptions used in its analysis. It analyzes eight agents using preliminary and dynamic analysis, supplemented by reverse engineering where feasible.

B. Prompt Injection Attacks

  • Direct prompt injection places malicious instructions in user input or the system prompt; indirect injection embeds them in external content the LLM consumes.The LLM may follow attacker-controlled instructions while referencing or summarizing that content.Source: B. Prompt Injection Attacks · p. 2

III. THREAT MODEL

  • The threat model targets violations of user-machine confidentiality or integrity through arbitrary data exfiltration or command execution.It assumes attackers leverage agent capabilities supported by built-in file and terminal tools.Source: §III · p. 2
  • The model includes workspace attackers and passive external attackers whose malicious content is inadvertently retrieved by the user or agent.External attackers cannot directly access the user’s machine.Source: §III · p. 2

IV. ANALYSIS

  • The analysis aims to identify exploitable design and implementation weaknesses in coding agents.The stated objective is to determine whether adversaries could use those weaknesses for malicious objectives.Source: §IV · p. 2

A. Targets

  • The eight targets span VS Code extensions and standalone applications or agents integrated into proprietary IDEs.For extension-based agents, the analysis uses environments where they are integrated into VS Code.Source: A. Targets · p. 2
  • The authors anonymize agent identities because responsible disclosure is ongoing.The target table distinguishes extension-based and IDE-integrated agents.Source: A. Targets · p. 2, Table I · p. 3

B. Analysis Approach

  • Preliminary analysis maps agent capabilities and attack vectors to possible workflows, while dynamic analysis monitors messages and internal state changes.A LiteLLM proxy or HTTP proxy captures exchanged messages, depending on endpoint configurability.Source: B. Analysis Approach · p. 3
  • Reverse engineering supplements runtime analysis because runtime behavior alone does not reveal implementation details.When proprietary server-side code prevents direct analysis, the authors rely on dynamic analysis.Source: B. Analysis Approach · p. 3

V. SYSTEMATIC ANALYSIS OF CODING AGENTS

The analysis traces how security issues across coding-agent components combine into end-to-end exploitation, while examining attack vectors and workspace customization under the threat model.

V. SYSTEMATIC ANALYSIS OF CODING AGENTS

  • The systematic analysis dissects agent components and their threats, then examines how issues combine into end-to-end exploitation.Prior work is described as fragmented or ad hoc, often limited to components or specific scenarios.Source: §V · p. 3
  • Five of eight agents have critical vulnerabilities in default settings: all five allow arbitrary command execution, and four permit global data exfiltration.The analysis also identifies 15 security issues that can combine into end-to-end exploitation.Source: §V · pp. 3–4

VI. ATTACK VECTORS

  • All analyzed agents exhibited at least one attack vector for indirect prompt injection under the threat model.The paper groups vectors into malicious workspaces, file resources, web resources, and tool descriptions.Source: §VI · p. 4

A. Malicious Workspace

  • Rule files and memory can carry direct prompt injections through workspace customization; all agents manage rule files in the workspace, but only A7 exposes memory to adversarial abuse.All agents except A1 inject rule-file prompts without notifying the user; A2 and A4 keep memory outside the workspace and inaccessible to adversaries.Source: A. Malicious Workspace · p. 4

B. Malicious File Resources

Malicious files and web content can inject prompts into coding agents, with directory listings providing an attack path that need not require opening a file.

B. Malicious File Resources

  • File contents can enter agent context when users view files or agents read them; A1, A2, and A4 include viewed files without additional approval, while other agents require approval for reading tools.An adversary controlling files or directories can inject prompts, including through a malicious third-party module in a Git submodule.Source: B. Malicious File Resources · pp. 4–5
  • Directory listings expose prompts in file or directory names without requiring users to open or read a specific file; A1, A3, and A8 include listings by default.Listings cover all subdirectories under the workspace, and other agents may expose them through tools such as list_dir.Source: B. Malicious File Resources · p. 5

C. Malicious Web Resources

  • Web-fetch, web-search, browser, and Git-related tools can expose agents to malicious web prompts, including through rendered pages, Git issues, or pull requests.The paper confirms web-resource prompt injection in coding agents using tools to retrieve web content.Source: C. Malicious Web Resources · p. 5

D. Malicious Tool Descriptions

Malicious tool descriptions can inject prompts after tools are installed, while weaknesses in tool-call validation can let attackers invoke tools the user did not intend to expose.

D. Malicious Tool Descriptions

  • Once installed, malicious MCP or extension tools can inject descriptions that affect agent behavior without further user action or notification.This vector assumes the user connects to a malicious MCP server or installs a malicious extension.Source: D. Malicious Tool Descriptions · p. 5

A. Threats in Tool Calling Mechanisms

  • Bypassing tool-call validation can let adversaries invoke tools not intended for agent use, circumventing user restrictions on capabilities.Built-in LLM tool-calling APIs provide basic validation, but agent-level validation remains necessary because LLM validation may be inconsistent.Source: A. Threats in Tool Calling Mechanisms · p. 6

B. Improper Tool Calling Validation in Anthropic API

  • Anthropic’s API does not check requested tool names against the agent’s available-tool list, allowing arbitrary tool calls; OpenAI, Gemini, and Grok validate against such misuse.The API parses Claude responses containing function-call tags and returns them to the agent in tool-calling format.Source: B. Improper Tool Calling Validation in… · p. 6

C. Improper Validation in Custom Tool Calling

Unvalidated custom tool-call requests can invoke disabled tools, while file-operation risks depend on access location and the files being accessed.

C. Improper Validation in Custom Tool Calling

  • Some agents using custom tool-calling mechanisms fail to validate incoming requests, allowing adversaries to invoke arbitrary tools.A3’s XML-based mechanism can execute write_to_file even in read-only mode; attempting execute_command additionally requires a safeguard bypass.Source: C. Improper Validation in Custom Tool… · p. 6

A. Threats in File Operations

  • File-operation threats include unauthorized reads and writes inside or outside the workspace, including access to configuration files and through symbolic links.The analysis categorizes read/write operations by workspace location and configuration files; A6 accesses files through its terminal tool rather than file-operation tools.Source: A. Threats in File Operations · p. 7, Table IV · p. 7
  • Most agents allow reads and writes within the workspace, while some also permit access outside it or writing to configuration files, creating security vulnerabilities.The paper identifies unauthorized file operations as risks to system confidentiality and integrity.Source: A. Threats in File Operations · p. 7

B. Unauthorized File Operation Outside the Workspace

Workspace file access and configuration can undermine security boundaries, while flawed terminal approval checks leave multiple routes to command execution. The risks include unauthorized reads and writes, approval bypass, and failures in command validation.

B. Unauthorized File Operation Outside the Workspace

  • A2, A4, and A7 permit external file reads; all agents except A8 mishandle external symbolic links, enabling workspace-controlled arbitrary reads or writes.A4 also permits external writes, which can place a malicious script in a startup location for persistent command execution.Source: B. Unauthorized File Operation Outside… · p. 7

C. Unauthorized Overwriting Configuration Files

  • A1’s writable workspace configuration can disable approval, while A2’s writable mcp.json can execute attacker-supplied commands when its MCP server starts.In A1, disabling approval removes user approval for all actions, including terminal operations.Source: C. Unauthorized Overwriting… · p. 7

IX. TERMINAL OPERATIONS

  • Terminal execution follows one of three approval paths, and incorrectly implemented safeguards permit arbitrary command execution, command injection, or disguised commands.The paths are execution without approval, LLM-based approval, or parsing followed by an allowlist check.Source: A. Threats in Terminal Operations · p. 8, Figure 3 · p. 8

B. Unsafe Approval Mechanisms

  • A7 disables terminal approval by default, while A3’s LLM-based approval can be bypassed by prompt injection that sets the approval tag to false.A3 enables LLM-based approval by default, but the approval requirement is represented in a user-manipulable message.Source: B. Unsafe Approval Mechanisms · p. 8, Table V · p. 8

C. Bypassing Command Parsing

Agents’ command parsers and allowlist checks can fail to stop malicious commands, and other agent features also present approval-bypass and data-exfiltration risks.

C. Bypassing Command Parsing

  • A1 and A2 incompletely validate shell metacharacters, allowing line breaks or command substitution to inject commands; A3 and A7 do not validate command inputs.A5 and A6 instead prompt users whenever special characters are detected.Source: C. Bypassing Command Parsing · p. 8, Table VI · p. 9

D. Bypassing Command Allowlist

  • A4 checks whether an allowed command appears anywhere in the input, so an allowed command in a comment can mask an executable malicious command.For example, if echo is allowed, “rm -rf * # echo” passes the check while only “rm -rf *” executes.Source: D. Bypassing Command Allowlist · p. 9, Table VII · p. 9

X. OTHER FEATURES

  • Extension-based tools, web fetch tools, and renderer features each present risks that can bypass approval or exfiltrate data.This section identifies these as three distinct feature areas for further security analysis.Source: §X · p. 9, Table VIII · p. 9

A. Approval Bypass by Extension-Provided Tools

Third-party tools can circumvent user approval, while unapproved web fetching and rendering can expose sensitive data to attacker-controlled servers.

A. Approval Bypass by Extension-Provided Tools

  • A1 lets extensions set approval requirements, and seven of the ten most-installed extensions exposing external tools require no approval for tool calls.The authors note this differs from A1’s built-in fetch tool, which always requires approval.Source: A. Approval Bypass by… · p. 9

B. Data Exfiltration via Web Fetch Tools

  • A4’s built-in web fetch tool requires no approval, allowing an adversary to exfiltrate context data or, with file-read and write primitives, arbitrary user-system files.The context includes system and workspace information and currently opened files.Source: B. Data Exfiltration via Web Fetch Tools · pp. 9–10

C. Data Exfiltration via Renderer

  • An attacker can manipulate rendered content to request an external resource with sensitive data, and the renderer does not require user approval.In A2, a malicious Mermaid image shape can trigger a request carrying sensitive data from the agent’s context.Source: C. Data Exfiltration via Renderer · p. 10

XI. END-TO-END EXPLOIT DEMONSTRATION

The paper demonstrates end-to-end exploits from attacker-controlled web resources that achieve serious security impacts without user interaction or approval. Two detailed cases show how prompt injection can lead to arbitrary command execution in A1 and A3.

XI. END-TO-END EXPLOIT DEMONSTRATION

  • Five agents were exploited for arbitrary command execution and four for global data exfiltration, without user interaction or approval.The authors define an end-to-end exploit as a malicious prompt that produces a significant security impact; web resources are assumed as the initial attack vector.Source: §XI · p. 10

A. Case 1: Arbitrary Command Execution in A1

  • In A1, malicious public web content prompts the agent to overwrite workspace settings and then execute arbitrary commands through the terminal tool.The attack changes autoApprove in settings.json; A1 permits the workspace file overwrite without approval, after which runCommands executes without approval.Source: A. Case 1: Arbitrary Command Execution… · pp. 10–11, Figure 5 · p. 10

B. Case 2: Arbitrary Command Execution in A3

C. Case 3: Global Data Exfiltration in A2

A malicious Git issue can induce A2 to read files outside the workspace and exfiltrate an API key through Mermaid rendering. The section also discusses prompt-injection and tool-misuse mitigations and their limits.

C. Case 3: Global Data Exfiltration in A2

  • A malicious Git issue can trigger A2 to read an API key outside the workspace and exfiltrate it through the Mermaid renderer to an attacker-controlled server.The attack proceeds through issue retrieval, arbitrary file reading, and rendering a diagram that sends the key; the scenario was tested using a private Git repository.Source: C. Case 3: Global Data Exfiltration in… · pp. 11–12

A. Defense Against Prompt Injection

  • Instruction-data separation can limit injection from external web or file content, but requires fine-tuned models and does not address direct prompt injection.The direct-injection cases include adversarial rule files or tool descriptions.Source: A. Defense Against Prompt Injection · p. 12

B. Tool Misuse Mitigation

  • Tool misuse stems from permissive tool policies, missing user-enforced controls, and implementation bugs.A tool-call guardrail could validate requests against policies, while sandboxing can confine execution; proprietary protocols can limit guardrail applicability, and arbitrary commands require comprehensive sandboxing.Source: B. Tool Misuse Mitigation · p. 12
  • Containerization isolates execution but adds management overhead, while seccomp can block legitimate network access unless configured more finely.A network-address allowlist is one proposed finer-grained configuration.Source: B. Tool Misuse Mitigation · p. 12

XIII. DISCUSSION

The paper reports 15 security issues across eight coding agents and demonstrates command execution and data exfiltration without user approval. It discusses disclosure outcomes, limits to generalizing the analysis, and how prior work differs from its focus on agent design.

A. Reponsible Disclosure

  • Vendors received reports of 15 issues; two were duplicated and two fixed with CVE IDs, while some were deemed intended behavior and excluded.The authors note that some exclusions reflected vendor security requirements because the threat model assumes a user-initiated attack, such as indirect prompt injection.Source: A. Reponsible Disclosure · p. 12, Table IX · p. 13

B. Non-coding Agents

  • Similar concerns may apply to general LLM agents, but their diverse tools make a unified threat model challenging and vulnerability analysis requires substantial manual effort.The paper cites EchoLeak in Microsoft 365 Copilot as an example involving email prompt injection and a Markdown-rendering bug to exfiltrate information.Source: B. Non-coding Agents · p. 13

XIV. RELATED WORK

  • Prior work examined VSCode extensions or generated-code security, whereas this analysis targets risks in coding agents’ design and built-in capabilities.The authors describe their work as the first in-depth coding-agent analysis uncovering attack primitives that can support end-to-end exploitation.Source: §XIV · p. 13

XV. CONCLUSION

  • The analysis found 15 issues across eight agents, enabling arbitrary command execution in five and global data exfiltration in four without user intervention or approval.The authors attribute the issues to insufficient policies and misimplementation bugs, and report that the issues can be chained into end-to-end exploitation.Source: §XV · p. 13

Related papers

Loading 2509.24240v1…