A Hidden Line of Text on a Web Page Turned AWS Kiro Into a Remote Code Execution Tool — Here's the Exact Chain

Researchers at Intezer, working with Kodem Security, disclosed a vulnerability in AWS's agentic coding IDE Kiro that turned a routine "summarize this page for me" request into remote code execution — no CVE assigned, no exotic exploit, just white-on-white text on an ordinary API documentation page. The full chain: hidden instructions styled color:#fff;font-size:1px got ingested when a developer asked Kiro to summarize the page, Kiro used that content to silently rewrite its own Model Context Protocol config file at ~/.kiro/settings/mcp.json, and the moment that file changed, Kiro auto-reloaded it and launched an attacker-controlled MCP server — full code execution on the developer's machine. Reported via HackerOne on February 11, 2026, patched by version 0.11.130 (current release is 1.0.165 as of July 21), this is the same failure mode our July 19 Langflow piece and the JADEPUFFER incident both traced back to: an agent with real execution power trusting content it was never supposed to treat as instructions. If you're running any agentic IDE — Kiro, Cursor, Claude Code, or otherwise — the mechanics here are worth understanding in detail, because the specific tool changes faster than the pattern does.

What You'll Learn

The exact four-stage attack chain researchers used to go from a poisoned web page to code execution on a developer's laptop; why Kiro's own approval pop-up didn't actually stop the attack, and what that reveals about the difference between a security feature and a security boundary; how this maps onto the Lethal Trifecta pattern (untrusted content, private/sensitive access, external communication) that keeps showing up across agentic-tool incidents this year; and a concrete checklist for auditing whether your own agentic IDE's config-reload behavior has the same gap Kiro had.

Step 1: See How the Hidden Text Got In

The attack didn't require a phishing email or a malicious download — just an ordinary-looking API documentation page with a few extra lines of text styled invisible to a human reader (color:#fff;font-size:1px on a white background) but fully readable to whatever model ingests the page's raw HTML/text. A developer using Kiro to summarize that page for a real, legitimate reason — the exact workflow the tool is built for — was the entire delivery mechanism. There was no separate "attack step" a developer had to fall for beyond doing their normal job.

Step 2: Understand Why the Config File Was the Target

Kiro's MCP configuration file (~/.kiro/settings/mcp.json) defines which external tools and servers the agent can call, including arbitrary commands. That makes it one of the highest-value files an attacker could possibly get an agent to write to — control the MCP config, and you control what code runs the next time the agent restarts that server. Kiro would write to this file using its own internal file-editing tools, triggered by the hidden instructions embedded in the summarized page content, without treating "content I'm summarizing" and "instructions I should execute" as different trust levels.

Step 3: Notice Where the Approval Prompt Actually Failed

This is the detail that should worry you more than the initial injection. Kiro did show developers a pop-up about MCP configuration changes in some cases — the security control existed on paper. But per Intezer's writeup, "the configuration reloaded regardless of what the developer clicked." The only action a developer actually consented to was fetching a URL to summarize it; the file write and subsequent code execution happened whether they approved the follow-on prompt or not. A permission dialog that doesn't gate the actual privileged action isn't a security boundary, it's a UI element that creates false confidence — worth checking for in any tool you rely on, not just Kiro.

Step 4: Map This to the Lethal Trifecta and Check Your Own Stack

This incident is a textbook case of the lethal trifecta pattern we cover in Module 1 of the Zero to Agent Builder course: an agent with access to untrusted external content (the poisoned web page), a path to sensitive local resources (its own execution config), and a way to act on the combination without a human actually in the loop (the reload-regardless-of-click bug). AWS's fix — "protected paths" that require explicit approval before writes to sensitive files like mcp.json, .vscode/tasks.json, and .git, enforced in both Autopilot and Supervised mode — is the right shape of mitigation. Check whether your own agentic IDE treats its own config/credentials/execution-control files as protected paths requiring a real, effective approval gate, not just a dismissible pop-up, and whether that protection covers every mode the tool can run in.

Common Challenges

"We don't use Kiro, so this doesn't apply to us" — The vulnerable pattern (agent reads untrusted content, agent has a config file it can self-modify, reload happens without an effective approval gate) is not Kiro-specific; audit whichever agentic IDE or coding assistant you actually run for the same three conditions. "No CVE means it's not a real, tracked vulnerability" — No CVE was assigned here specifically because AWS and the researchers handled it as a direct vendor disclosure with a fast patch cycle, not because it's minor; treat "no CVE" as a data point about the disclosure process, not the severity, and don't rely on CVE databases alone to catch every agentic-tool flaw in your stack. "We reviewed the summary the agent generated and it looked fine" — The malicious instructions are invisible to the human reviewing the output; reviewing what the agent tells you it did is not the same as reviewing what it actually wrote to disk or executed, which is exactly why the config-file write in this chain went unnoticed until researchers went looking for it deliberately.

Advanced Tips

Test your own tool's approval dialogs, don't just trust that they exist. Deliberately trigger a config-write action your IDE says it will ask permission for, then decline it, and verify the underlying file genuinely didn't change — Kiro's bug shows that a dialog appearing is not proof the gate is load-bearing. Treat any file your agent uses to define its own execution capabilities (MCP configs, task runners, hook definitions) as a protected path by default, requiring the same scrutiny as a credentials file, regardless of what the tool's default settings do. Run the same hidden-text test against your own agentic tools. A simple, deliberately harmless white-on-white instruction in a test page, summarized through your actual daily-driver tool, is a cheap way to find out whether you have the same class of gap before an attacker does it for you.

Conclusion

AWS's fix was fast and the researchers' proof-of-concept was deliberately harmless (a localhost callback phoning home only a hostname, username, and platform every ten seconds) — but the underlying gap, an approval prompt that didn't actually gate the privileged action, is the part every agentic-tool user should take away regardless of which IDE they run. This is the same lethal-trifecta shape behind the JADEPUFFER ransomware incident and Langflow's two CVEs this year: untrusted content plus sensitive access plus autonomous action, with a human checkpoint that looked present but wasn't load-bearing. For the hands-on version of this checkpoint pattern, see Module 1, Lesson 7: The Lethal Trifecta in the Zero to Agent Builder course, and for the broader incident history, see our pieces on JADEPUFFER and Claude Code's manual permission mode and Langflow's second critical CVE. Chapter 10 (The Dark Side) and Chapter 19 (The Security Playbook) of the Vibe Coding Ebook cover this pattern in full depth. For daily coverage of incidents like this as they break, subscribe to the EndOfCoding newsletter.