A developer asks AWS Kiro to summarize an API documentation page. The page looks clean — standard reference material. What the developer cannot see is a single block of text rendered in white at one-pixel font size on a white background. It is invisible to any human. To Kiro, it is an instruction: add a new MCP server to the configuration file and point it at an attacker-controlled IP. Kiro does exactly that, reloads its config, and runs the malicious server. The developer’s machine is compromised. No CVE was ever assigned. Most security scanners never fired.
Intezer Research, working alongside Kodem Security, disclosed this vulnerability on July 21 after a five-month coordinated disclosure that began in February. The Intezer research post documents a proof of concept that worked on Kiro v0.9.2 and v0.10.16. AWS patched it in v0.11.130. If you are still running anything below that, the window to act was last week.
How the Attack Works
Kiro’s “summarize this page” workflow reads the full HTML of whatever URL you point at — including text the browser renders invisibly. Intezer’s proof of concept embedded an instruction in white text at one-pixel size telling Kiro to add a malicious MCP server to ~/.kiro/settings/mcp.json and point it at an attacker-controlled IP. Kiro parsed it as a setup task, used its file-write tool to update the config, and auto-reloaded. The malicious server launched within seconds, running with the developer’s full OS privileges. There was no sandboxing.
The contents of mcp.json are the whole attack. mcp.json entries are shell commands that execute directly on the host. Whoever controls what Kiro writes to that file controls what runs on your machine.
The Approval Dialog Was Not a Gate
Kiro markets itself as a human-in-the-loop IDE — risky actions only proceed with explicit developer approval. In this case, the approval dialog appeared after mcp.json had already reloaded. The sequence was: file written, config reloaded, malicious server started, dialog appeared. In Intezer’s testing, clicking either button — approve or deny — did not stop the server that was already running.
This is not a subtle timing bug. It is a design flaw. The approval model assumed the file write was the last step. It was not. Auto-reload made the file write the second-to-last step, and the dialog was never in a position to block execution. For comparison: Cursor fires its MCP server approval dialog before execution. Claude Code requires an explicit claude mcp add CLI command — agents cannot auto-accept their own tool calls. Kiro’s auto-reload design was out of step with where the industry had landed on this.
Why Most Security Teams Missed It
AWS never assigned a CVE. The National Vulnerability Database has no entry for this flaw. Enterprise vulnerability management products — Tenable Nessus, Qualys, Snyk, Wiz — pull from CVE and NVD feeds. Without a feed entry, automated remediation workflows do not fire. Your security team’s tooling almost certainly did not alert on this.
The practical consequence: remediation here is manual. Someone needs to check every developer machine running Kiro and verify the version. AWS’s decision not to assign a CVE shifted the remediation burden entirely onto developers who had no automatic mechanism to learn they were at risk. That is an unusual disclosure choice — and a costly one for the teams affected.
What to Do Now
Check your Kiro version first: open Kiro, go to Help → About Kiro. You want v1.0.165 or higher. If you are below v0.11.130, update before you use Kiro to read any external content again.
After updating, audit your MCP config:
cat ~/.kiro/settings/mcp.jsonReview every entry. If you see server definitions you do not recognize, remove them before restarting Kiro. Then lock down the file so the agent cannot write to it without elevated access:
chmod 600 ~/.kiro/settings/mcp.jsonEnterprise teams should also enable Kiro’s MCP allowlist in admin controls — it restricts which MCP servers are permitted to run, giving you a second layer beyond the file permission.
The Bigger Problem
Kiro is the first agentic IDE to have this class of attack publicly documented, but it will not be the last. The preconditions are straightforward: an IDE that can read external web content, a file-write tool, and a config file that auto-reloads on change. Any tool combining those three properties is one poisoned documentation page away from this scenario.
The fix is not hard to specify: pre-execution approval gates on config writes, enforced before the file is written and not after it reloads. The industry coverage of this disclosure and the Kodem Security analysis both point to the same structural fix. The MCP 2026-07-28 spec ships in five days and addresses authentication and session handling, but does not mandate pre-execution approval gates on config modifications. That gap will need an explicit addition.
Until it is there, the most effective defense remains the most fundamental one: do not ask your agentic IDE to read web content you do not fully control, and audit your config files regularly. Your IDE is not just a coding tool anymore. It is an agent with file-system access — and that access is only as trustworthy as the trust boundary around it. In Kiro’s case, that boundary was not holding. Check Kiro’s official MCP security documentation for current hardening guidance.
