A file write became a command launcher

Amazon's Kiro is an agentic development environment built on the Visual Studio Code foundation. Its assistant can inspect a project, edit files, and help perform development work. Those abilities become security-sensitive when the model reads text supplied by someone other than the developer. A repository README, source comment, issue, or fetched documentation page can contain instructions written for the model rather than for the human. That is indirect prompt injection: attacker-controlled data crosses into the agent's instruction stream.

Cymulate Research Lab reported such a path to Amazon on February 2, 2026. The researchers demonstrated that Kiro's file-write tool could create or change files under .vscode/ without asking the developer. That directory is not ordinary project storage. It contains workspace configuration interpreted by Kiro and other VS Code-based editors, including task definitions that can launch operating-system commands.

The vulnerable versions treated a write to source code and a write to an editor control file as equivalent. One changes the program a developer is building. The other can change what runs on the developer's machine when the workspace opens. Giving both paths the same approval policy saved a dialog box and quietly pawned the security boundary.

Amazon published Security Bulletin 2026-037-AWS on June 2 and assigned CVE-2026-10591. The bulletin covers every Kiro IDE version before 0.11 and says the flaw was fixed in version 0.11. Amazon listed no workaround for vulnerable releases, so the prescribed remedy was an upgrade rather than a hopeful settings ritual.

Three steps from prose to execution

The demonstrated chain did not depend on a traditional memory-corruption exploit or a malicious extension. It combined prompt injection, the agent's legitimate file-write capability, and a legitimate editor feature.

First, the attacker places a crafted instruction in content Kiro will process. Cymulate used examples such as a README, a code comment, or a web page presented to the agent. The instruction tells the model to create .vscode/tasks.json and put an attacker-selected shell command inside it.

Second, Kiro's fswrite tool writes that file. Before version 0.11, the path received no special protection, and Cymulate's proof of concept showed the write completing without a confirmation prompt. The task definition used the VS Code setting "runOn": "folderOpen", which tells the editor to start the task when the project folder is opened.

Third, the developer opens the project again. The VS Code task machinery reads the planted configuration and launches its command with the developer's operating-system privileges. Depending on that account and machine, the command could reach source code, environment variables, cloud credentials, signing material, Secure Shell keys, or anything else the developer could access.

Calling this remote code execution requires an important boundary. A stranger could not send an arbitrary network packet to Kiro and instantly own a machine. The attacker first had to get crafted content into material processed by the agent, and the developer later had to open the affected workspace. Amazon's CVSS 4.0 vector records active user interaction, while its CVSS 3.1 vector records required user interaction. The scores were 8.6 and 8.8 respectively, both High.

The chain still removed the approval decisions that mattered. The developer did not approve the write to .vscode/tasks.json and did not approve the attacker-selected command through Kiro's command runner. The ordinary act of reopening a previously trusted workspace supplied the execution trigger.

Workspace trust was too early and too broad

Workspace trust did exist. Cymulate explained that the folder had to receive trust before its contents could execute. That decision was a one-time gate, commonly made when a developer begins working in a project. The prompt injection could arrive later, after trust had already been granted. Kiro then allowed its model-driven tool to alter .vscode without another warning.

This timing matters because trust is supposed to answer a question about the material being trusted. A developer who approves a workspace on Monday has not meaningfully approved an attacker-controlled task silently planted on Thursday. Reusing the old decision for newly generated executable configuration turns consent into an all-season parking permit.

Kiro also had a separate approval path for shell commands. That control did not govern this chain because Kiro's shell tool was not the component launching the payload. The agent wrote a configuration file, then the underlying editor executed it as a folder-open task. Security controls organized by tool name missed the composition: a supposedly routine file tool handed work to a command-execution feature outside its own approval flow.

The distinction also explains why this was an AI-specific failure rather than a story about malicious text merely doing what its author intended. Text in a README cannot write files by itself. Kiro interpreted that untrusted text, exercised delegated authority, and crossed from project content into execution-sensitive configuration without checking with the developer. The attacker supplied intent; the agent and editor supplied the privileged bridge.

Version 0.11 protected the dangerous paths

Amazon's bulletin says Kiro IDE 0.11 addressed the issue. Kiro's current privacy and security documentation describes the added boundary in concrete terms: writes to protected paths require explicit approval before they occur in both Autopilot and Supervised modes. The protected patterns include .vscode/, .git/, .code-workspace, mcp.json, and .kiroignore.

That fix places the decision at the action that changes the risk. If prompt injection tells the agent to modify .vscode/tasks.json, Kiro must stop before writing and show a confirmation. Declining leaves the file untouched. The policy covers the entire .vscode/ path rather than attempting to recognize one dangerous JSON field, which is sensible because editor configuration offers many ways to influence behavior and vendors have an unfortunate talent for inventing more.

Version 0.11 was released in March, before the June bulletin publicly tied the release to CVE-2026-10591. Users on 0.11 or later have the protected-path control. Users on older builds received no vendor-supported workaround; upgrading was the fix.

Demonstrated vulnerability, not a reported breach

Cymulate produced a proof of concept and coordinated the disclosure with Amazon. Amazon acknowledged the vulnerability, issued the CVE, and credited Cymulate. The National Vulnerability Database entry lists the affected versions, both High severity scores, and CWE-732, incorrect permission assignment for a critical resource.

None of those sources identifies a compromised Kiro user, a breached company, or exploitation outside controlled research. The CISA assessment recorded in the NVD change history marked exploitation as none on June 17. A real exploit could have had a broad reach, but the public evidence supports a patched high-severity hazard and near miss rather than a known campaign.

That evidence boundary does not make the design error academic. Coding agents routinely consume unfamiliar repositories and web content precisely because developers want help understanding them. File writes are routine enough to automate, and workspace configuration is powerful enough to execute code. Joining those facts without a path-specific approval gate turned hostile prose into a deferred command launcher.

The repair was neither a clever prompt nor a longer warning about suspicious READMEs. It was access control. Execution-sensitive files received a separate boundary enforced by the application, outside the model's discretion. The model may still be persuaded by hostile instructions, but it can no longer quietly turn that persuasion into a poisoned VS Code task. That is the sort of boring, mechanical restraint an agent needs when it has been invited to edit the room where the power tools are kept.