AWS Kiro IDE and Kiro CLI — eight 2026 CVEs disclosed only through AWS security bulletins, the newest (CVE-2026-89332, 2026-09-11) an agent-written workspace setting that exfiltrates workspace data before the user answers the approval prompt; three CVSS 8.5 'open a malicious project directory and code runs' bugs; a stdin trick that skips the tool-approval prompt

View raw markdownEdit on GitHub ↗

TL;DR

AWS's agentic IDE Kiro (and its terminal sibling Kiro CLI) has accumulated eight 2026 CVEs beyond the MCP-config self-rewrite bug this repo already tracks, every one disclosed through an AWS Security Bulletin (AWS is the CNA) and mirrored as an unreviewed GitHub Advisory Database entry with no package metadata — so no Dependabot alert, no changelog "security" line, and no press. The newest, CVE-2026-89332 (bulletin 2026-111-AWS, 2026-09-11; NVD CVSS 4.0 6.7 / 3.1 5.5): in an untrusted workspace, crafted repository content could make the Kiro agent modify the workspace settings file to point the Kiro Powers registry URL at an attacker endpoint; the user saw a prompt showing the change, but the file was already on disk, so opening the Powers panel before answering sent workspace data out. Fixed in 0.8.135 (a patch dated 2026-01-14 on Kiro's changelog — the CVE arrived eight months after the fix). The rest: three CVSS 8.5 workspace-trust bypasses where opening a crafted project directory executes code — CVE-2026-4295 (IDE < 0.8.0, CWE-829), CVE-2026-18656 (IDE < 1.0.228 on Windows, CWE-427 uncontrolled search path) and CVE-2026-18657 (CLI < 2.10.0 on Windows, same class, both 2026-08-04); CVE-2026-9255 (CLI < 1.28.0, CVSS 8.4) — piping content to stdin bypassed the tool-authorization prompt and ran shell commands with no approval; CVE-2026-0830 (IDE < 0.6.18, 8.4) — command injection through workspace folder names in the GitLab merge-request helper; CVE-2026-5429 (IDE < 0.8.140, 7.1) — XSS in the Agent webview via a colour-theme name; and CVE-2026-11931 (IDE < 0.11.133 on macOS/Linux, 6.8) — the auth token cache was world-readable (0644). Run current Kiro (IDE ≥ 1.0.228, CLI ≥ 2.10.0), and if a pre-fix Kiro ever opened a repository you did not write, rotate what that project could see.

What happened

Kiro is AWS's VS Code-derived agentic IDE (spec-driven "Powers," an autonomous agent with file-write and shell tools, MCP support) and ships a companion CLI. Like Claude Code's and Cursor's advisory indexes, Kiro's security record lives somewhere no {tool} vulnerability search surfaces — here, AWS's bulletin feed — and this sweep found it by walking github.com/advisories?query=kiro, where every entry is marked "unreviewed" with empty version fields. The bulletin numbers below are the vendor record; the GHSA copies carry the NVD scores.

CVE-2026-89332 — the agent writes a setting, the data leaves before you say no (bulletin 2026-111-AWS, 2026-09-11). AWS: the vulnerability "allows a Kiro agent to modify a workspace's settings file in an untrusted workspace. A malicious repository could redirect the Kiro Powers registry URL to an external endpoint, exfiltrating sensitive workspace data. Although users received a prompt displaying the changes and URL before approval, the file was already written to disk, enabling data transmission if the Powers panel opened before the user responded." NVD (CNA AWS) scores it CVSS 4.0 6.7 (AV:L/AC:L/AT:N/PR:N/UI:A/VC:H), CWE-201 + CWE-829. Affected < 0.8.135; AWS's remediation: upgrade, and "rotate any credentials present in a project opened on an earlier version" — no workaround. Two things to notice. First, the approval dialog was cosmetic: the write happened, the prompt came after, and a separate code path consumed the written value — the same "the dialog shows the claimed action, not the real one" shape as the GhostApproval class. Second, the trigger is repository content, i.e. prompt injection through files the agent reads, which is the MCP-config self-rewrite chain again with a different sink (settings.json → Powers registry URL instead of mcp.json → MCP server). Kiro's changelog dates patch 0.8.135 to 2026-01-14; the CVE and bulletin are from 2026-09-11. Date the bug by the fix, not the CVE.

Three "open the folder and code runs" bugs (all CVSS 8.5). - CVE-2026-4295 (published 2026-03-17; GHSA-qpcc-2ccj-gp68): "improper trust boundary enforcement in Kiro IDE" — a remote unauthenticated actor "executes arbitrary code via maliciously crafted project directory files that bypass workspace trust protections when a local user opens the directory." CWE-829. Affected < 0.8.0. - CVE-2026-18656 (bulletin 2026-074-AWS, 2026-08-04; GHSA-hhmj-6g9r-9vvq): uncontrolled search path element (CWE-427) in Kiro IDE on Windows — a crafted project directory "containing an executable that bypasses workspace trust protections" runs when the directory is opened. Affected < 1.0.228. - CVE-2026-18657 (same bulletin date; GHSA-vr58-qjgp-x52v): the identical bug in Kiro CLI on Windows when "a local user starts Kiro CLI in the directory." Affected < 2.10.0. The Windows pair is the Cursor git.exe binary-planting pattern: the tool resolves a helper executable from the current directory before the system path, so a repository ships its own. "Workspace trust" that runs a binary from the workspace before asking whether to trust the workspace is not a trust boundary.

CVE-2026-9255 — stdin skips the approval prompt (CLI, bulletin 2026-035-AWS, 2026-05-26; CVSS 8.4). "Missing input source validation in Kiro CLI tool authorization" — a local attacker "bypass[es] tool authorization prompts by piping malicious content to stdin, enabling execution of arbitrary shell commands without user approval." CWE-862. Affected < 1.28.0. The approval prompt read its yes/no from the same stream an attacker could pre-fill; anything that can write to the CLI's stdin (a wrapper script, a compromised terminal multiplexer, another local process) answers the question for the user. Compare Claude Code's 50-subcommand deny-rule bypass: both are cases where the gate had a bug rather than the tool behind it.

CVE-2026-0830 — command injection through a folder name (IDE, 2026-01-09; CVSS 8.4). "Processing specially crafted workspace folder names could allow for arbitrary command injection" in the GitLab merge-request helper (CWE-78). Affected < 0.6.18. A directory name is attacker-controlled the moment a repository is cloned.

CVE-2026-5429 — XSS in the Agent webview (IDE, 2026-04-02; CVSS 7.1). A malicious colour theme name rendered unsanitised in the Agent webview; a remote attacker gets code execution once "a local user opens a workspace and trusts it when prompted." Affected < 0.8.140. The webview is the agent's chat surface — script there can read and inject into the agent's conversation.

CVE-2026-11931 — world-readable auth token cache (IDE, 2026-06-15; CVSS 6.8). The authentication token cache file was created 0644 instead of 0600 on macOS and Linux, so any local user could read Kiro's (AWS Builder ID / IAM Identity Center) tokens. Affected < 0.11.133; permissions are corrected on the next token refresh after upgrading, and AWS recommends re-authenticating on shared machines. Same class as the Claude Code /copy temp-file finding and the Codespaces/devcontainer multi-user cautions elsewhere in this repo: an AI tool's credential cache is a credential file.

What the batch says about the vendor channel. Eight CVEs in nine months, three at 8.5, none with a project-side advisory, changelog security note, or blog post; the fix for the newest CVE shipped in January and the CVE landed in September. This is the corporate-parent bulletin rule (IBM/Langflow, NVIDIA/NemoClaw) applied to AWS: aws.amazon.com/security/security-bulletins/ is the disclosure channel for Kiro, Amazon Q Developer and the awslabs.* MCP servers, and the GHSA copies are unreviewed mirrors that cannot drive tooling. Kiro's IDE version line also jumped from 0.x to 1.0.228, so a "0.8.135" fix reads as ancient — but the CVE for it is new, and the recommendation (rotate what the project could see) is not time-limited.

Am I affected?

# Kiro IDE / CLI versions
kiro --version 2>/dev/null; kiro-cli --version 2>/dev/null
# Any agent-written changes to workspace settings pointing at a registry you don't recognise
grep -rn 'powers\|registry' .kiro/settings*.json .vscode/settings.json 2>/dev/null
# Token cache permissions (macOS/Linux)
find ~/.kiro ~/Library/Application\ Support/Kiro ~/.config/Kiro -name '*token*' -perm -o+r 2>/dev/null
# Windows: unexpected executables at the root of any repo you opened in Kiro

You are affected by CVE-2026-89332 if a Kiro IDE older than 0.8.135 opened any repository you did not author; by the Windows search-path pair if Kiro IDE < 1.0.228 or Kiro CLI < 2.10.0 opened such a directory on Windows; by CVE-2026-9255 if anything untrusted could write to Kiro CLI's stdin on a version < 1.28.0; by CVE-2026-11931 if Kiro IDE < 0.11.133 ran on a multi-user macOS/Linux host.

If you are affected

  1. Upgrade to current Kiro IDE (≥ 1.0.228) and Kiro CLI (≥ 2.10.0) — all eight are fixed in those or earlier lines.
  2. For any repository a pre-0.8.135 Kiro opened: rotate every credential that project directory contained or that the agent could read (.env, cloud profiles, tokens) — AWS's own guidance. → playbooks/rotating-cloud-credentials.md
  3. On shared macOS/Linux machines that ran Kiro < 0.11.133, sign out and re-authenticate so cached tokens are invalidated. → playbooks/if-your-github-pat-leaked.md (same rotation shape for Builder ID / SSO tokens)
  4. If a crafted directory was opened on a vulnerable Windows build, treat the machine as having run attacker code. → playbooks/if-your-local-ai-agent-was-exploited.md

Prevention

  • → prevention/agent-sandboxing.md — open untrusted repositories in a container or VM first; "workspace trust" dialogs in every AI IDE tracked here have had a bypass.
  • → prevention/credential-hygiene.md — keep secrets out of the project directory the agent reads; a settings file the agent can write is a config file the agent can weaponise.
  • Subscribe to the AWS security-bulletin feed for Kiro and Amazon Q rather than the project changelog; the changelog for 0.8.135 says nothing about security.

Sources