Loading today’s stories
Security1 distinct publisher3 min readPublished
The path Mindguard reported works against Kiro 0.7.45 on Windows and Amazon closed it in 0.8.140, but no CVE was assigned and workspace trust made no difference, so the installed version string is the only check you have.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
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.
Ranked by verification strength, evidence, and original report placement.
Researchers at Mindguard disclosed a vulnerability in Amazon Kiro, an AI-powered agentic integrated development environment, that could facilitate data exfiltration via prompt injection and Kiro Powers.
The flaw works against Kiro IDE 0.7.45 on Windows, according to Mindguard.
Security researcher Fergal Glynn said the issue allowed attacker-controlled repository content to influence the Kiro agent and ultimately cause sensitive local information to be transmitted to an external endpoint.
Kiro Powers bundles Model Context Protocol server configurations, steering files ("POWER.md"), hooks and contextual knowledge; the steering file is described as an onboarding manual that provides persistent context and tells the AI agent what MCP tools are available and when to use them.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 27, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Grok built its own prompt injection: the filter never saw the payload1 distinct publisher
security
The credential store nobody inventoried: MCP servers now hold the keys to everything they touch1 distinct publisher
build
Kubernetes MCP servers hide the delete tool; hiding is not removing1 distinct publisher
build
Amazon Q executed code from any repo you opened, and it is not the only one1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific and internally consistent, but single-source and unverified
The disclosure carries unusually concrete technical detail for a single-source story: named researcher, tested build (0.7.45 on Windows), exact trigger sequence, an explicit trust-boundary sequence, and a named fix build (0.8.140), plus corroborating precedent in CVE-2026-10591 and Intezer's finding. It is capped well below high confidence because all of it is relayed from one vendor report in one outlet, there is no CVE record or Amazon advisory to check against, no independent reproduction, and the 'low difficulty' rating has no stated methodology.
Vendor remediation shipped; real-world exposure unmeasured
There is hard evidence of remediation activity - a fix shipped in Kiro IDE 0.8.140, a prior Kiro fix for CVE-2026-10591, and a broad set of comparable fixes across other agentic tools - which shows the class of defect is being acted on in production tooling. It stays low because the sources give no Kiro installed base, no telemetry on how many installs sit below 0.8.140, no evidence of exploitation in the wild, and no enterprise deployment or policy response.
Slightly overstated by single-vendor framing
The reporting is largely restrained - it states the required user actions, names the fixed build, and does not claim in-the-wild abuse. The mild overstatement comes from carrying the disclosing vendor's own 'low exploitation difficulty' rating without independent scoring, from the headline-level framing that a workspace file plus one message is enough while the non-default File > Open Workspace From File path is a real precondition, and from stacking an ecosystem-wide vulnerability roundup around an already-patched issue.
Vendor research marketing plus disclosure-driven outlet
The primary material is a report Mindguard shared with a security news outlet, quoting its own researcher; publicising named flaws in a high-profile Amazon AI product is direct marketing for an AI-security vendor, and this is the firm's second publicised Kiro steering-file finding. The outlet's incentive is traffic from vendor-supplied exclusives, evident in the long appended roundup of other tool vulnerabilities. Countervailing: the researchers went through responsible disclosure and the vendor fix is acknowledged, so the incentive is toward visibility rather than unfixed-risk hype.
Moderate: detailed but unreplicated single source
Confidence is moderate because the technical specifics are precise and mutually consistent and a vendor fix corroborates the core defect, but the entire cluster rests on one publisher relaying one vendor report, with no CVE record, no Amazon statement, no independent reproduction, and no data on exposure or exploitation.