AWS Kiro: how invisible text on a web page led to code execution — and what the fix teaches about AI coding agents

What happened?

Security researchers documented an attack chain against AWS Kiro, Amazon's AI-powered coding agent: a seemingly harmless request like “summarize this page” could end in remote code execution. The trick was hidden text on a crafted web page (hidden via CSS, e.g. color:#fff;font-size:1px) — Kiro processed this text like any other page content while summarizing.

From that hidden text, Kiro derived instructions that got it to write entries into ~/.kiro/settings/mcp.json without explicit approval. On reload, Kiro automatically executed the commands registered there — with the developer's own privileges. In the proof-of-concept payload, the executed code “phoned home” with the machine's hostname, username, and platform every ten seconds.

The flaw was reported on February 11, 2026; AWS shipped the fix by April 3, 2026. The chain was only documented and discussed more widely in public now, in mid/late July 2026 — which is why it's only now coming into view for many operators despite the earlier patch date.

Why this matters technically

The core of the problem is a recurring pattern in AI coding agents: configuration files that contain code automatically executed at the next opportunity (here, mcp.json) weren't treated as especially sensitive — until someone showed that an agent can write to them itself, in the course of a seemingly harmless task. This is the same basic class of weakness as GhostApproval (the symlink bypass in AI coding agents) or the Miasma/Friendly Fire incidents already covered on this blog: the trust boundary between “external content read by the agent” and “consequential action generated by the agent itself” wasn't drawn sharply enough.

What's notable about AWS's response is the fix chosen: a “protected-paths” system that marks mcp.json, .vscode/tasks.json, the .git directory, and other sensitive files as requiring explicit approval — in both autonomous (“Autopilot”) and supervised mode. That's a structurally different approach from pure prompt filtering: instead of trying to detect malicious instructions in page content, it limits the effect, regardless of where the instruction came from.

What operators should check

Immediate steps for current Kiro users

# Check Kiro version:
kiro --version

# Affected: Kiro 0.9.2 (macOS), 0.10.16 (Ubuntu), and earlier
# Patched: from 0.11.130 onward; the current 1.0.x line
# (capability-based permissions model) is recommended

# Apply updates via the official Kiro download page/update channel,
# not by manually patching configuration files.

Fundamental questions for any AI coding agent in use

• Which of the agent's own configuration files contain entries that get executed automatically on next launch (MCP server definitions, task-runner configs, shell hooks)?
• Does the agent require explicit approval before writing to these files — including in autonomous mode?
• Is web content the agent processes as part of a task (summarizing, research, documentation) fundamentally treated as potentially instruction-bearing?

These questions can't be answered blanket-style with “apply the update” if your own agent isn't Kiro — but AWS's pattern (protected paths with mandatory approval) is a useful yardstick for any comparable tool.

Conclusion

The Kiro case isn't an isolated incident but another confirmation of a pattern that keeps recurring in 2026: AI coding agents that process web content while also having write access to security-relevant configuration need a hard boundary between reading and acting — and that boundary has to hold regardless of how plausible or harmless the triggering request looked.

Sources

This analysis draws on The Hacker News's reporting on the Kiro attack chain and AWS's fix.