How Invisible Web Text Turned AWS Kiro Into an RCE Tool

A researcher asks AWS Kiro's agentic IDE to summarize a web page. Ten seconds later, a Node.js process on their laptop is beaconing their hostname and username to a server in another country. Nobody clicked a malicious link. Nobody ran an untrusted script. The only action the developer actually approved was "fetch this URL."

That's the shape of the vulnerability Intezer and Kodem Security reported in Kiro, and it's a clean, almost textbook example of what OWASP calls Excessive Agency meeting indirect prompt injection. It's worth walking through slowly, because the interesting part isn't the payload — it's which approval step got skipped.

The attack, step by step

Kiro is an agentic IDE: it can browse the web, edit files, and run Model Context Protocol (MCP) servers on your behalf. Like most agent tools shipped in the last two years, it has a permission model — some actions need a human to click "approve" before they run.

Here's how the researchers broke it, as covered by The Hacker News:

1. An attacker plants hidden instructions on an otherwise ordinary web page — say, API documentation a developer would plausibly ask an agent to summarize. The text is styled white-on-white at a 1-pixel font size, so it's invisible in a browser but fully present in the HTML.
2. A developer asks Kiro to fetch and summarize that page. This is the only step they consciously approve.
3. Kiro pulls the page into its context. The hidden text gets treated the same as any other content on the page — including as instructions.
4. Following those instructions, Kiro uses its file-write tool to rewrite ~/.kiro/settings/mcp.json, the file that lists which MCP servers Kiro launches on startup and what command starts each one.
5. Kiro reloads that config automatically and starts the newly-registered "server" — really just an attacker-chosen command, in the proof of concept a node -e one-liner that phoned home every ten seconds with the machine's hostname, username, and platform.

Steps 4 and 5 are the part that should have required a human. They didn't. As one of the researchers put it: "the file that decides what code Kiro will execute is itself writable by the agent without review."

Why this isn't a one-off bug

A few things make this worth your attention beyond "patch your Kiro install."

No CVE was assigned, which is notable given the severity — arbitrary code execution with full developer privileges, reachable from a single summarization request. AWS did patch the underlying issue in Kiro 0.11.130, and the 1.0.x line went further, adding capability-based permissions that require explicit consent before previously-unapproved action types can run — a real fix, not just a bigger warning dialog.

It's not unique to Kiro. Researchers have now documented well over 30 similar prompt-injection-to-RCE paths across agentic coding tools — Cursor's Windows executable-search-order flaw (still unpatched as of this writing, and disputed by Cursor as in-scope), similar issues reported in GitHub Copilot, and an earlier, separate Kiro bug from 2025 where injected instructions in source comments got Kiro to allowlist arbitrary bash commands. The pattern is always the same shape: a legitimate editor feature (fetch a URL, open a repo, read a file) becomes the delivery mechanism, and a config or settings file that the agent trusts becomes the escalation point.

MITRE ATLAS has a name for the delivery half of this: indirect prompt injection (AML.T0051.001) — malicious instructions embedded in external content the model ingests rather than typed by the user. OWASP's LLM Top 10 covers both halves: LLM01 Prompt Injection for the delivery, LLM06 Excessive Agency for the fact that a summarization request could reach a file-write-and-execute capability at all.

What guardrails actually catch here, and what they don't

This is the case study we'd point to for why AgentGuards screens content in both directions, not just user prompts. Two distinct things had to go wrong for this attack to work, and they call for two distinct checks:

• Content screening on fetched web content. The hidden-text payload is a textbook indirect-injection pattern — instructions embedded in ingested content rather than the user's own message. Our prompt-injection checker and inline guardrails are built to flag exactly this: a page whose extracted text contains directive language ("create a file at...", "run this command...") gets scored and can be blocked before it ever reaches the model's context, independent of whether it's visible to a human eye.
• Action authorization on the write/execute step. Content detection is necessarily probabilistic — a sufficiently obfuscated or novel injection can slip past any classifier. The second layer that matters is treating "write to a config file that governs process execution" as a privileged action requiring explicit authorization, the same way file deletion or credential access should be gated. That's the piece AWS's 1.0.x fix added natively, and it's the same principle behind our OWASP Agentic Top-10 mapping and action-authorization approach for coding-agent integrations.

To be precise about what we're claiming: we can't tell you with certainty that AgentGuards would have caught this specific proof-of-concept payload, because that depends on where in Kiro's pipeline a guardrail is wired in and how the specific payload was phrased. What we can say is that the two failure points in this attack — unscreened content reaching agent context, and an unapproved privileged file-write — are exactly the two things our input/output screening and OWASP-mapped guardrails are designed to catch. Defense in depth here means neither layer has to be perfect on its own.

If you want to see the delivery mechanism in action rather than just read about it, we recorded a short demo of the exact pattern — hiding instructions inside a document an agent is asked to summarize, and watching it comply.

▶ Watch: Live hacking demo: how we created a new Claude Code agent and hacked the repo with it

The takeaway for anyone shipping an agentic tool

If your agent can write to any file that influences what code runs next — an MCP config, a tasks.json, a .bashrc, a CI file — that file needs the same approval friction as running rm -rf, regardless of how the write request originated. "The user approved a web fetch" is not the same thing as "the user approved everything that fetch triggers," and treating them as equivalent is exactly the gap this vulnerability lived in.

If you're integrating an agentic coding tool into your workflow, check whether it treats its own config and permission files as protected paths, and whether "supervised mode" actually blocks on approval or just shows a notification after the fact — Kiro's own documentation reportedly noted that supervised mode is "a code review workflow, not a security control." Worth confirming before you trust it with one.