AWS Kiro 被曝间接提示注入可致任意代码执行

On the day AWS Kiro was released, I couldn’t resist putting it through some of my Month of AI Bugs security tests for coding agents.

AWS Kiro was vulnerable to arbitrary command execution via indirect prompt injection. This means that a remote attacker, who controls data that Kiro processes, could hijack it to run arbitrary operating system commands or write and run custom code.

In particular two attack paths that enabled this with AWS Kiro were identified:

Allowlisting arbitrary Bash commands (.vscode/settings.json); Adding malicious MCP servers (.kiro/settings/mcp.json)

An often-overlooked aspect is that the AI itself could compromise the developer’s machine, either because of hallucinations, a hidden backdoor in the model, or just as a means to achieve a certain task.

Here’s how the vulnerabilities worked in practice.

Kiro can write to files without the developer’s approval, meaning there is no user interaction required for writing to files.

Kiro stores information about allowlisted Bash commands in the .vscode/settings.json file.

Since the agent can write to the file without the developer’s consent it is possible to allowlist Bash commands. For instance, one can add the following line:

A third party attacker can exploit this via an indirect prompt injection to achieve arbitrary command execution.

Here you can see the result:

Besides popping a calculator, we also modified the color scheme of Visual Studio Code, all with the power of prompt injection.

Video Walkthrough

In case you prefer a video to reading through all the etails below, I also put together a 10 minute video that walks through discovery and explains it all in much detail.

Indirect Prompt Injection Payload

For the demo I just put the prompt injection into a source code file as a comment. This exploit does not require the user to compile the code or execute it. It just requires the user to chat with the project or code.

However, it is important to understand that the attack can also come from other places, like embedded in file uploads, or from untrusted data returned from tool calls, or MCP servers,…

In this case the attack allowlists all Bash commands by adding an asterisk (*) to the allowlist, and it sets VS Code color theme to red.

This demonstration allowlists all commands for the Bash tool!

The result is that the AI will be hijacked, follow instructions and compromise the developer’s machine.

After allowlisting all commands, the proof-of-concept launches the Calculator application, all without the developer’s consent or interaction besides running a prompt.

Video Demonstration

Here is a short video demonstration of the PoC:

But wait, there is more!

Adding Malicious MCP Servers

While researching I noticed that MCP servers are configured in a different file under the .kiro folder, in particular this settings file .kiro/settings/mcp.json.

Knowing this, we can also add a malicious MCP server on the fly with custom code.

As you can see, it added the custom python code in to the MCP settings, and when it saved the file immediate code execution took place and the calculator launched.

For reference here is the payload that caused this:

The prompt injection payload could also be delivered via other means, e.g the response of a tool call, or an uploaded image for example. It being in the source code is one example attack vector.

Impact and Severity

AI systems that can break out of their sandbox and compromise a developer’s machine sounds like science fiction. But as we have now seen multiple times, it is becoming a recurring and serious security flaw in the way many vendors design agents.

Such vulnerabilities should be seen at least as CVSS high severity (range 7.0-8.9), and there is an argument to be made that they are even critical IMHO, especially as stakes rise and agents are run on the main workstations of developers.

I’m pretty convinced that systems with such vulnerabilities will allow agents to exploit them on their own in the future. The reason for this is that agents will be able to read their own documentation to learn about config options, and e.g. figure out how to allowlist commands to achieve objectives.

Recommendation and Fixes

Initial disclosure to AWS on release day July 15, 2025; Recommendations provided included to not write files to disk without the developer approving, and move sensitive options like allowlisted Bash commands into the user’s profile rather than the workspace; AWS addressed the vulnerabilities quickly (reflecting its high severity) by August 5, 2025. Reported as fixed in v0.1.42; No CVE was issued; AWS does not offer a public bug bounty program to reward this kind of research

Shout out to the Kiro and AWS security team for getting this vulnerability addressed quickly.

Conclusion

AWS Kiro was capable of reconfiguring itself and achieve arbitrary code execution. An attacker could force this condition via indirect prompt injection, coming from source code, an uploaded image, or data returned from tool calls.

As we have shown with GitHub Copilot and Amp earlier this month already, and now with AWS Kiro, Agents that can modify their own configuration to achieve arbitrary code execution enable sandbox-like escapes, where the AI breaks out and compromises the developer’s machine.

References

Newer →; Contact me; ← Older