CivSafe — Strategic Innovation. Community Impact.

This dropped on August 27 and it's the kind of thing your dev team needs to hear about today, not next sprint.

Mindguard disclosed a prompt injection vulnerability in Amazon Kiro, Amazon's agentic AI-powered IDE. The vulnerability lets an attacker craft a malicious workspace file, wait for someone to open it, and then have the Kiro agent silently exfiltrate sensitive data from that developer's machine — without the developer ever asking the AI to do anything of the sort.

Amazon has patched it. But the mechanics of how this attack works tell you something important about a much bigger surface area problem.

What Kiro Powers Is

If you haven't used Kiro, here's the quick background: it's Amazon's answer to Cursor and Windsurf, an IDE with a deeply integrated AI agent that can browse your codebase, run commands, fetch URLs, and orchestrate complex workflows. The agent is designed to be agentic by default — it takes initiative.

Kiro has a feature called Kiro Powers. Think of it as a bundle that configures the agent: it includes MCP server settings, hooks, contextual knowledge, and a steering file called POWER.md. The steering file is the key thing here — it's essentially an onboarding manual for the agent. It tells the AI what tools are available, what it should do automatically, how to behave in this project.

If an attacker controls what's in that POWER.md, they control how the agent behaves.

How the Attack Works

The attack requires two things to happen:

The user opens the project through File → Open Workspace From File (not by simply opening a folder)
The user sends any message to the Kiro agent

That's it. After those two things, attacker-controlled instructions in the workspace's steering file tell the agent to transmit sensitive local data to an external endpoint. The user's actual message doesn't matter. It's the trigger.

Mindguard's assessment: exploitation difficulty is low.

Worth repeating: the data leaves "without the user explicitly requesting that Kiro access or transmit" it. The user thinks they're asking the agent to summarize a file or explain some code. The agent is doing that, plus silently doing what the steering file told it to do.

The CVE Problem

Amazon patched this in Kiro version 0.8.140. That's the fix. Update now if your team uses Kiro.

But here's what's worth paying attention to: Amazon did not assign a CVE to this vulnerability.

No CVE means it won't show up in vulnerability scanners. It won't trigger a notification from your software inventory tooling. It won't get flagged in a compliance report. The only way someone finds out is if they read security news or their tooling has active version-based checks on IDE software (most don't).

This is the second time in a few months Amazon has patched a serious Kiro flaw without a CVE. Back in June, CVE-2026-10591 (CVSS 8.8) covered remote unauthenticated RCE via crafted instructions — that one did get a CVE, because Intezer pushed for it. Mindguard's disclosure this week did not get the same outcome.

This is not unusual behavior from vendors. It keeps your patch invisible. That's a problem.

Why This Hits Small Orgs Differently

Big orgs have security teams monitoring new vulnerability disclosures, software inventory with version tracking, and update policies with enforcement. They'll catch this.

Small dev teams — a 5-person startup, a nonprofit with two developers, a 20-person agency — often don't.

The specific workflows that create exposure here are also common in smaller shops:

You work with external contractors who share project files or workspace configurations
You evaluate open-source repos by opening them directly in your IDE
Your team shares workspace presets or project templates with custom AI configurations
You accept workspace files from clients as part of project onboarding

Any of those create a path for a malicious POWER.md to land in your IDE. After that, the next conversation you have with the Kiro agent is when the exfiltration runs.

What's in your project directory right now? Probably .env files. Database connection strings. API keys. Cloud credentials. SSH configs. All of that is readable by an agentic IDE — that's the entire point of giving it access to your workspace.

What To Do Right Now

If your team uses Kiro: update to version 0.8.140 or later immediately. This is not a "put it on the backlog" situation. The fix is already out.

Audit how you open projects. The attack requires using "File → Open Workspace From File." That's a specific flow. If your team opens projects by opening folders directly, this specific attack doesn't trigger. But it's worth knowing which flow your team actually uses day-to-day.

Treat workspace files like untrusted input. A .kiro-workspace file (or equivalent) that bundles a custom POWER.md is now a potential attack artifact. If someone sends you a workspace configuration, that's as meaningful as them sending you code to run. Review it before opening it.

Stop keeping plaintext secrets in project directories. This is good practice regardless of Kiro. If your AI agent can read your .env file, anyone who can influence that agent can read it too. Use a secrets manager, or at least keep credentials out of the project tree.

Check your AI IDE version policy. Most IDE auto-updates happen in the background, but agentic IDEs have system-level access. They should be on your software inventory list and on a version-monitoring process, same as any other tool with that level of access.

The Broader Pattern

Kiro is not uniquely bad here. This vulnerability class — prompt injection through attacker-controlled workspace content — applies to any agentic coding tool that reads configuration or context files from the project directory. Cursor, Windsurf, and others all use similar patterns. The specific mechanics differ, but the trust boundary is the same: a file in your repo can influence what the agent does next.

We've seen this pattern with .cursorrules, with .github/copilot-instructions.md, with MCP server configurations. Attackers have noticed that these files are read and acted on. The attack surface is not going away — it's growing as agent capabilities expand.

The question for your team is not whether you trust the IDE vendor. It's whether you trust every file in every project the agent will ever read. That's a much harder bar.

This is one of the things we look at when we do AI tool security reviews for small teams — mapping which tools have access to what, and what the injection surface looks like. If your team has adopted a few agentic tools in the last year without a security pass, it's worth knowing where you stand.