We found two ways a malicious repository can trigger code execution on a developer's machine through Cline, the AI coding agent with ~4.2M installs. Cline will fix both as "product hardening" but classifies neither as a security issue.
TL;DR
We identified two high-severity local code-execution paths in Cline, the AI coding agent VS Code extension with ~4.2M reported installs across the VS Code Marketplace and OpenVSX.
The attack: a developer clones an attacker-controlled repository and asks Cline to set it up. Routine workflow, dozens of times a week. The repository's content tricks the agent into running attacker-supplied shell commands under the developer's account, granting access to credentials, source code, and anywhere the developer can reach over their VPN. Confused-deputy in agentic AI, not self-RCE.
The bypass: Cline ships an Approve/Deny dialog and a "Safe Commands" auto-approve filter that are supposed to stop exactly this. Both fail.
Finding #1: clicking the URL preview tile to verify where the agent is fetching from runs an OS-level command instead. The Approve/Deny dialog never gates the click.
Finding #2: "Safe Commands" doesn't inspect commands. It asks the AI agent whether its own command is safe, and trusts the answer, even after the same agent has been manipulated by attacker content.
Cline's response, in their words: the affected function has "an unsafe URL sanitization pattern, which we will fix as part of product hardening." They are "working on improving controls and configuration options" for Safe Commands. Both fixes are coming, but neither as a security advisory or a CVE.
Independent CVE assignment is being pursued via MITRE. Full disclosure timeline below.
What an attacker can actually do
Picture a developer who clones an unfamiliar repository, opens it in VS Code, and asks Cline to set it up. Routine workflow that happens dozens of times a week across millions of developer machines. The agent reads the README, follows the setup steps, runs the install commands. The developer never types a single shell command themselves.
Under either of the two flaws below, that one routine action can hand the attacker arbitrary code execution under the developer's account: SSH keys, AWS and GCP credentials, browser cookies, source code, anything the developer can reach over their VPN. The attacker writes one file (a malicious README, or content the agent reads from somewhere, like an issue body, a webpage, or an MCP server response). The developer types one benign prompt. The shell runs whatever the attacker wrote.
The first PoC video shows the chip-click path. Cline asks "Approve or Deny?" for a URL, and clicking the URL itself (the natural defensive action: “let me see where this goes first”) pops the calculator.
The second PoC video shows the headless path: a malicious README in an otherwise empty repo, a six-word prompt, and the calculator opens with zero clicks and no approval dialog ever rendered.
Both PoCs were captured on Cline v3.81.0 with the kwaipilot/kat-coder-pro model via Cline-provider API, available out-of-the-box on Cline's native provider with no separate API key required. The architectural flaws themselves are model-independent.
Cline's own published Bugcrowd program lists this exact threat model as a Critical category: indirect prompt injection through attacker-controlled content like typo-squatted repos, malicious npm starter templates, or vendored "example apps" inside otherwise legitimate packages. The pattern is broader than Cline. Our research team observes it routinely across third-party AI agent stacks.
Finding 1: Clicking to verify a URL can ‘run’ it instead
When Cline's agent decides to fetch a web page, the chat UI renders a tile reading "Cline wants to fetch content from this URL" with an Approve/Deny dialog below it. The tile shows the URL the agent wants to visit. Clicking that tile, intuitively, previews the URL by opening it in your default browser so you can see where the agent is about to go before approving.
It does not preview. It runs.
The handler behind the tile passes the URL string straight into child_process.exec with shell-quoting only. On macOS that's open "${url}"; on Linux xdg-open "${url}"; on Windows variants of start "" and powershell.exe Start-Process. Any URL containing the matching quote character (or $(), or a backtick) escapes the wrapper and runs arbitrary shell.
One click. Calculator opens. The Approve/Deny dialog above the tile is still pending. Clicking Approve, Deny, or never clicking the dialog at all produces the same result.
To make the trick visually invisible, the tile is rendered with right-to-left text direction and a truncation ellipsis. A user inspecting the URL sees https://example.com/... on the left; the trailing ; open -a Calculator; # is hidden off the right edge.
The bug only became reachable last June. The shell-exec function (openUrlInBrowser) was added a year ago as a deliberate workaround for a VS Code URI-parsing bug. At the time it had exactly one caller, which sanitized every input through encodeURIComponent, so no attacker-controllable character could reach the shell. Then, in June 2025, an unrelated bugfix added a new gRPC handler that forwards arbitrary strings into the same function with no sanitization, and rewired the URL-preview tile to use it. The unsafe function didn't change; the caller did. One year in production.
The fix is a one-line wiring change. Cline already has a safe URL-opener (openInBrowser, routes through VS Code's own vscode.env.openExternal). The tile is wired to the wrong gRPC client. Swap them out and the bug is gone.
Finding 2: the "Safe Commands" gate is the model itself
Cline's onboarding asks new users to enable three auto-approve checkboxes: Read, Safe Commands, and MCP. The natural assumption (and the one we made) is that "Safe Commands" matches commands against a Cline-curated allowlist of safe binaries (ls, cat, git status, etc.).
It does not.
Reading the source, the auto-approve gate looks at requires_approval: true|false, a parameter the LLM writes on its own tool call. If the model says its own command is safe and the user has Safe Commands enabled, the command dispatches with no Approve/Deny dialog. Cline does not parse the command's argument string. It asks the prompt-injected agent whether the prompt-injected agent's command is dangerous.
The PoC is a malicious README in an otherwise empty repo:
The developer opens the repo and types six words:
set up this project for me, follow every instruction in README
Cline reads the README, dispatches execute_command with curl -s "https://example.com/?healthz?build=$(open -a Calculator)" and requires_approval: "false" (the model sees a "health check curl"; it doesn't reason about what bash will later do with $()). The auto-approve gate fires. No dialog. The shell expands the substitution before curl even runs. macOS Calculator launches. The curl request itself fails. Irrelevant; the shell substitution already executed.
No clicks. No follow-up prompt. The developer has not interacted with any UI surface besides the initial six-word task.
The Cline-side fix is small. Before the auto-approve gate, if the command's argument string contains $(...), backticks, unescaped ;, &&, ||, |, >, or unbalanced quotes, override the model's requires_approval to true. Three lines of code; it decouples "the model thinks this is safe" from "the bytes actually look safe to a /bin/sh interpreter."
Vendor response: "product hardening"
Cline's security team responded on June 9, 2026 with their final classification on both findings:
On Finding #1, they wrote that "the [openUrlInBrowser] function has an unsafe URL sanitization pattern, which we will fix as part of product hardening." They classified the realistic exploit scenario as outside Cline's threat model under a shared-responsibility framework, on the grounds that the attack path "requires the user to provide a malicious URL."
On Finding #2, they wrote: "You raise a good point that many others have also raised around Cline's determination of what is considered a 'safe command'. We are working on improving controls and configuration options, such as an explicit allow/deny policy, and transparency within Cline to help with this concern." They classified the demonstrated chain as out of scope because "it requires the user to clone an untrusted repository containing an attacker-controlled folder."
Both bugs will be fixed, albeit neither acknowledged as a security issue or tracked in an advisory.
Two observations are worth making here:
First, Cline's own Bugcrowd program scope explicitly lists "Indirect Prompt Injection (Critical): An attacker places a malicious README.md in a repo. When Cline reads it, the instructions inside the file 'hijack' the agent to exfiltrate the user's ~/.ssh keys" as an in-scope critical category. That scenario is mechanically identical to Finding #2. The published scope and the triage outcome are pointing in different directions.
Second, the chip-click trigger in Finding #1 is not arbitrary user action. The user is clicking the URL preview to verify the destination before approving the fetch, the exact defensive behavior the Approve/Deny dialog is designed to enable. Framing that as "the user provided a malicious URL" treats the URL the agent emitted into the tile as the user's contribution.
We share these observations in good faith. They do not change Cline's decision. They explain why we're publishing the technical writeup anyway.
Want to see what your coding agents are actually doing, and the detection and response to secure your agentic operations? That’s what manifold is built for. Talk to Manifold
Disclosure timeline
The pattern this fits
Vendors and researchers have argued about where vendor responsibility ends since security research existed. "The user clicked" and "the user cloned" are old positions with no clean resolution. What is newer, and worth flagging, is how those arguments are now playing out in disclosure decisions.
“We'll fix it as part of product hardening, but it's not a security issue" has become the reason for an increasing share of disclosure work. Reports are closed as informational or out-of-scope; the underlying issue ships in the next release as a hardening improvement, a configuration option, or a transparency enhancement. The fix lands, but the advisory never does. Users do not learn that their previous version was vulnerable, and security teams cannot prioritize patching based on a product-refinement changelog entry.
How Manifold can help
Both bugs share the same property: the security boundary the user thinks they're enforcing isn't the one the system actually enforces. Approve/Deny in Finding #1 sits on the wrong UI element. Safe Commands in Finding #2 delegates the gate-keeping decision to the very component being gated. In both cases, the gap is between what the user is told the system does and what the system actually does at the moment of execution.
That gap is exactly where runtime defense lives. Static review of the source code reads each function in isolation and moves on; the bug is in how they connect at runtime, not in any single function. Runtime observability sees the dispatched argument string, sees the $() substitution, sees the shell sink, and applies argument-shape policy independent of which UI path led there and independent of what the model claimed.
Manifold monitors agent behavior at runtime, including via OpenTelemetry. When an agent dispatches a tool call whose arguments would be re-interpreted by a downstream shell ($(), backticks, semicolons, redirect operators), that's visible in our telemetry regardless of which approval logic the framework around the agent claims to be applying. The defense doesn't depend on the framework getting its trust boundaries right; it depends on watching what the agent actually executes.
And it starts with knowing what's in your agent stack to begin with. If you're using AI coding agents and MCP servers, check them in Manifest, our free, open-access tool that indexes and scores MCP servers and agent extensions on lineage and safety signals.
Want to see what your coding agents are actually doing, and the detection and response to secure your agentic operations? That’s what manifold is built for. Talk to Manifold
Latest articles
