Amazon Kiro Can Leak Your Files Just Because You Opened a Project

• The Mess: A malicious Kiro workspace can manipulate Amazon’s AI coding agent through prompt injection and make it read sensitive local data and send it to an attacker-controlled server. No malicious prompt is required from the developer.
• The Damage: An attacker can turn an ordinary project repository into a data-exfiltration channel, potentially exposing source code, configuration files, credentials or other sensitive workspace data.
• The Fix: Update Kiro to 0.8.140 or later, and treat untrusted repositories as hostile input when using agentic development tools.

You don’t have to type the malicious prompt.

You don’t even have to ask Kiro to read the secret.

Opening the wrong project can be enough.

Security researchers at Mindgard found a prompt-injection vulnerability in Amazon Kiro, an AI-powered agentic development environment. The attack allows attacker-controlled repository content to influence the Kiro agent and ultimately exfiltrate sensitive information from the developer’s machine.

Amazon has since fixed the issue in Kiro 0.8.140.

The Repository Is the Trap

The attack starts with a malicious workspace.

The attacker places instructions inside project-controlled content.

Kiro reads that content as part of its normal agent workflow.

That’s where the boundary disappears.

A traditional IDE sees a malicious README or directory name as data.

An AI coding agent may interpret the same content as instructions.

And Kiro has tools capable of acting on those instructions.

No Evil Prompt Required

This is the detail that makes the vulnerability nasty.

The developer doesn’t have to paste:

“Send my secrets to this server.”

They don’t have to explicitly tell Kiro to access sensitive files.

According to the research, exploitation can occur after the victim opens a specially crafted workspace and sends any message to the agent.

The malicious instructions are already sitting inside the project.

The AI does the rest.

Kiro Powers Become the Exit Route

The attack abuses Kiro Powers.

These extend Kiro’s capabilities using components such as MCP server configurations, steering files and hooks.

That extra functionality is useful for developers.

It also gives an injected instruction more ways to interact with the machine.

The attack chain effectively becomes:

malicious repository → Kiro agent → sensitive local files → Kiro configuration/capability → external request

The attacker doesn’t need a conventional malware executable.

The agent becomes the execution mechanism.

The Victim’s Machine Does the Work

This is what makes agentic IDE vulnerabilities different from ordinary prompt injection.

The model isn’t just generating text.

It can:

• read project files
• access local information
• modify files
• invoke tools
• interact with network resources

Every capability makes the development workflow more useful.

Every capability also creates another place where an injected instruction can cross a security boundary.

Mindgard rated exploitation as low difficulty and reproduced the issue against Kiro 0.7.45 on Windows.

This Isn’t Kiro’s First Security Problem

Kiro has already had other security issues involving malicious project content and agent behavior.

Earlier research led to CVE-2026-0830, a command-injection vulnerability where opening a maliciously crafted workspace could lead to arbitrary command execution in vulnerable Kiro versions. AWS fixed that issue in Kiro 0.6.18.

That history matters.

The problem isn’t simply one badly constructed prompt.

It’s the architecture.

Kiro is designed to allow an AI agent to interpret project content and perform actions on behalf of the developer.

That creates a very different attack surface from a normal editor.

The Security Boundary Is the Problem

Developers normally assume that opening a repository is relatively safe.

The code may be untrusted.

But a text file is still a text file.

An agentic IDE changes that assumption.

A malicious file can become an instruction.

The instruction can influence the model.

The model can invoke a tool.

The tool can access data.

And another capability can transmit it.

Nothing in that chain necessarily looks like traditional malware.

That’s the problem.

What Developers Should Do

The immediate action is simple:

Update Kiro.

Amazon says the vulnerability was fixed in version 0.8.140.

But patching isn’t the entire solution.

Developers should also treat unfamiliar repositories as potentially hostile when opening them in AI-powered IDEs.

Don’t mount sensitive credentials into an environment that an autonomous agent can access unnecessarily.

Don’t give an AI agent unrestricted access to your entire home directory.

And don’t assume that because something is called a README, workspace file or configuration file, it is harmless.

With agentic development tools, data can become instructions.

Bugstoday Opinion

This is where AI coding tools get uncomfortable.

The selling point is simple:

Give the agent your project and let it do the work.

The security problem is equally simple:

Give the agent your project and the project can tell the agent what to do.

That’s a terrible trust boundary.

The attacker doesn’t have to jailbreak the model.

They don’t have to steal your password first.

They can put instructions inside the thing you’re about to open.

And once the AI has access to your filesystem and network tools, the difference between reading code and following code becomes dangerously thin.

Bugstoday verdict: if opening an untrusted repository can give its contents influence over an AI agent with access to your files, the repository isn’t just untrusted code anymore. It’s an untrusted operator sitting next to your keyboard.

Today’s Bugs. Tomorrow’s Breaches.