AWS patched a silent Kiro RCE in April, disclosed today

AWS patched a remote code execution flaw in Kiro, its agentic coding IDE, back on April 3. Intezer and Kodem Security published the details today, July 21, with The Hacker News writing it up the same morning. Nicole Fishbein at Intezer and Eran Segal at Kodem reported it via HackerOne on February 11. The gap between the fix and the public write-up is the honest timeline — AWS shipped a fix quietly, no CVE assigned, no security bulletin big enough to make anyone update urgently, and the details land three months later after everyone on 0.11.129 or older already ran a version the researchers say could be triggered by asking the agent to summarize a web page.

What was actually broken

Kiro’s agent could write to ~/.kiro/settings/mcp.json on the developer’s own machine without going through the approval step the UI implied was there. That file is the Model Context Protocol server list — anything Kiro will spawn and hand tool access to. A page rendered inside the agent’s context could smuggle in instructions telling it to add a new MCP entry. On the next run, the entry executes. No prompt shown to the user.

The class here is not novel. It’s the same trust boundary every agentic IDE has been failing at all month: the agent is treated as a trusted local process, but its inputs (web pages, files, git diffs) are not. When one of those inputs can write to a config the agent reads next, sandboxing the agent does nothing — the payload lives outside the sandbox. Pillar walked variants of this out of Cursor, Codex, Gemini CLI, and Antigravity last week. Zhang et al. walked it out of five open-source Android agent frameworks the day before that. Kilobaud framed the general pattern here. Kiro is the same story with an AWS logo on it.

What AWS actually shipped

v0.11.130 (April 3) added mcp.json, .vscode/tasks.json, and the .git directory to a protected-paths list. Writes to those now require explicit approval in both Autopilot and Supervised mode. AWS also stated the obvious thing out loud in its response to the researchers: Supervised mode is a code-review workflow, not a security control. That line is worth pinning above whoever on your team is pushing agent-driven code review as risk mitigation.

Current Kiro is 1.0.165 as of today. Anything from v0.11.130 forward has the fix. Anything older — 0.9.2 on macOS and 0.10.16 on Ubuntu are the versions the researchers verified — does not.

What to actually do

Priority is low-to-medium, not fire drill. Intezer confirmed no in-the-wild exploitation as of publication, and the version cutoff was three months ago. But if you have Kiro deployed across a developer fleet, do these in order:

1. Inventory Kiro versions across dev laptops. kiro --version in a management-tooling sweep. Anything 0.11.129 or earlier gets updated from Kiro downloads today. Anyone on 1.0.x is already patched — don’t waste the cycle chasing them.
2. Baseline ~/.kiro/settings/mcp.json on every developer machine. If a workstation was running an affected version for any window this year, that file could already carry an unauthorized MCP entry from a page the developer opened. Compare against a known-good template, flag deltas.
3. Look for the actual persistence, not the entry. An MCP entry alone is just a config line. The interesting question is what got run the next time the agent started. Correlate mcp.json modification times against process-execution telemetry from the same host and window — anything new that isn’t a legit dev tool warrants a look.
4. Deprioritize retro-hunt beyond that. No CVE, no CVE-ID to grep for in alerts, no SIEM rule shipping from a vendor. The forensic signal is what the added MCP server did on your host — the injection itself lives in the browsing history and is not durable.

The broader read

AWS did the responsible thing on timing (patch first, then disclose), and declining to file a CVE for what they view as a design fix is a defensible call. The problem is that “no CVE, no bulletin urgency” means the same customers who trust AWS to secure Kiro also trust AWS to tell them when Kiro was insecure — and the signal here was so quiet that “patched three months ago” and “you were exposed until you next launched the updater” are the same sentence for most fleets. If your patch pipeline for developer tools depends on release notes to escalate, this one did not escalate.

Prioritize the developer-tool inventory the same way you prioritize the browser inventory. The pattern this week is not slowing down.