Mindguard shows a Kiro workspace file and one message are enough to exfiltrate local data

Any message will do. Mindguard's trigger condition is not a crafted prompt: once the malicious workspace file is open, the developer can ask the agent anything, and the attacker's instructions are already in context without the developer ever referencing them ^[11]. The attacker-controlled material is repository content. The surface it reaches is Kiro Powers, which bundles MCP server configurations, steering files named POWER.md, hooks and contextual knowledge, with the steering file acting as the agent's persistent onboarding manual for which MCP tools exist and when to call them ^[6].

Mindguard puts the failure across the whole sequence rather than at one call: repository content influences the agent, the agent reads sensitive local information, the agent writes that information into security-relevant IDE configuration, and a later IDE capability turns the modified configuration into network activity ^[12]. Workspace trust does not gate any of it. The researchers reproduced the flow in both trusted and untrusted workspaces ^[8].

The version picture is short and worth getting right. The tested build was 0.7.45 on Windows ^[3]. The fix landed in 0.8.140 ^[13]. The current release is 1.0.337 ^[4]. Anyone on the current line is past the patch, and anyone still on a 0.7.x install sits below it ^[2]. There is no CVE identifier ^[2], so nothing arrives in a feed to tell you which side you are on: the check is the installed version string rather than a scanner hit ^[1].

This is Mindguard's second exfiltration route through the same steering-file surface. The earlier one had a crafted steering file read a local file and render it into a Markdown image request aimed at an external server ^[14]. It is also the second Kiro configuration-write problem Amazon has fixed: in June 2026 the company addressed CVE-2026-10591, rated CVSS 8.8, where crafted instructions caused writes to execution-sensitive paths such as ".vscode/tasks.json" or "~/.kiro/settings/mcp.json" and produced auto-execution on folder open ^[15]. Intezer's description of that bug states the primitive plainly: hidden instructions in a web page Kiro reads make Kiro rewrite its own MCP server configuration file and gain arbitrary code execution, with no approval prompt shown ^[16]. Different entry point, same terminal step ^[3].

Mindguard does not say why the workspace-file path triggers where opening the folder directly does not, which is the detail anyone writing a detection or a policy control needs most. The finding is also reported only against Windows ^[3], with no statement either way about macOS or Linux builds. What is public is the fix version, the two required actions ^[7], and the difficulty rating, which Mindguard assessed as low ^[10]. Those two actions are how a developer normally starts work on somebody else's repository.