Kiro’s Eighth CVE of 2026 Is the Same Bug Class as Its Third

2026-09-25 AI Vulnerabilities & CVEs by al-ice.ai Editorial

AWS published security bulletin 2026-117 on September 24, assigning CVE-2026-95985 to Amazon Kiro IDE. The CNA description is short and the mechanism is worth reading closely: the file write tool in Kiro IDE before 1.0.242 "might allow remote unauthenticated actors to inject crafted instructions into the agent's context. When a user runs the agent in a crafted repository as an untrusted workspace, sending any message can cause agent modifications to auto-loaded global configuration paths."

AWS scores it CVSS 3.1 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and CVSS 4.0 8.6, with two weaknesses: CWE-829, inclusion of functionality from an untrusted control sphere, and CWE-349, acceptance of extraneous untrusted data with trusted data. There is no public proof of concept, no credited external reporter in the CVE record, and no claim of exploitation.

Three sentences, three distinct failures

The description compresses more than it appears to. Unpacking it:

"Inject crafted instructions into the agent's context." Repository contents — README files, source comments, configuration, documentation — are read into the model's context. The tool treats the workspace as data, but the model treats it as language. This is indirect prompt injection with the repository as the delivery channel, which is why AWS rates the attack vector as network with no privileges required: the attacker's contribution is a file in a repo someone clones.

"As an untrusted workspace." Kiro has a trust designation for folders, inherited from the VS Code lineage. The critical detail is that the flaw applies in the untrusted mode. Marking a workspace untrusted is the action a careful developer takes precisely to contain a repository they do not trust. If the restricted mode does not restrict the agent's write scope, the control is doing the opposite of its advertised job — it produces confidence without producing containment.

"Sending any message." There is no unusual request required. The user does not have to ask the agent to read the malicious file, review the project, or touch anything sensitive. Any interaction starts the turn, the poisoned context is already loaded, and the write follows. The CVSS UI:R flag is technically accurate and practically near-meaningless: the required user interaction is opening a folder and typing.

Why writing `~/.kiro` is an escalation, not a file edit

An integrity impact of HIGH on a config file only makes sense once you see what the file does. The global Kiro configuration directory is auto-loaded, and it is where an agentic IDE keeps the things that define its own behaviour — steering and rules documents that enter every future context, and MCP server definitions, which are literally a command plus arguments that the IDE launches as a subprocess.

So the primitive is: content in repository A obtains write access to the configuration that governs the agent's behaviour in every repository, forever. The workspace boundary was the containment model, and a write to a global auto-loaded path crosses it in one step. Two consequences follow. First, persistence — a poisoned steering file survives closing the malicious project and keeps influencing work on unrelated code. Second, potential execution, if the written entry defines a tool server whose command the IDE later starts.

AWS's own remediation guidance confirms the persistence concern rather than the exploit chain: users who ran the agent in an untrusted workspace on an earlier version "should also review the global Kiro configuration directory (~/.kiro) for entries they did not create." A vendor asking users to audit a directory for foreign entries is telling you the artifacts outlive the patch. Note what the advisory does not say: it does not assert code execution was demonstrated. The honest reading is a confirmed cross-workspace configuration-write primitive whose downstream severity depends on which auto-loaded file the agent was steered into writing.

This is the second time this year, in the same tool, through the same tool call

In June, AWS published CVE-2026-10591 — "Insufficient access control restrictions in the file write tool in Amazon Kiro IDE before version 0.11," where crafted instructions caused writes to execution-sensitive paths such as .vscode/tasks.json, enabling auto-execution on folder open. Same component, same root shape, same CVSS 8.8 / 8.6 pairing. That one was fixed by restricting writes to a set of sensitive paths.

And in July, Intezer and Kodem published research showing a poisoned web page could make Kiro rewrite its own mcp.json and execute code, a chain AWS patched without assigning a CVE.

The pattern across all three is one defect expressed three ways: the agent's file-write capability is scoped by path denylist rather than by the provenance of the instruction that requested the write. A denylist enumerates the dangerous destinations known at the time it was written — .vscode/tasks.json in the June fix — and each subsequent CVE names a destination the previous list omitted. The September issue lands on global config paths that the earlier protected-path work did not cover in the untrusted-workspace case.

The NVD keyword index for Kiro IDE now returns eight CVEs published in 2026: command injection through crafted workspace folder names (CVE-2026-0830, January), improper trust boundary enforcement (CVE-2026-4295, March), a webview XSS to code execution (CVE-2026-5429, April), the file-write path issue (CVE-2026-10591, June), an authentication token cache readable by other local users on macOS and Linux (CVE-2026-11931, June), a Windows uncontrolled search path element (CVE-2026-18656, August), untrusted functionality inclusion in the Kiro Powers feature (CVE-2026-89332, September 11), and now CVE-2026-95985. Read together, that is not a tool with an unlucky bug; it is a tool whose trust boundaries are being discovered incrementally by disclosure.

What would actually fix the class

The structural fix is provenance tracking rather than destination filtering. Once untrusted content has entered a context window, every subsequent tool call in that turn should inherit a reduced capability set — a taint model. Under that design, the specific question "is ~/.kiro/steering on the protected list?" stops mattering, because a write requested in a turn containing untrusted repository content cannot reach outside the workspace regardless of the path.

This is the same conclusion the tool-allowlisting research reached from the defensive side, and the same boundary failure visible in Manus's obfuscated-email chain: the model is not a reliable adjudicator of which text in its own context is an instruction, so the enforcement has to sit outside the model. A second observation follows for the trust designation itself. If "untrusted workspace" is to mean anything for an agentic IDE, it has to bound what the agent can write, not merely what the editor auto-runs. Inheriting a trust model designed for extensions and task runners, then adding an agent with a general-purpose file-write tool, leaves the control naming a boundary it no longer enforces.

What to do

Upgrade to Kiro IDE 1.0.242 or later. AWS names this as the remediation floor; anything below it is affected per the CVE's version range (all versions less than 1.0.242).
Audit ~/.kiro for entries you did not create, per AWS's explicit guidance, if the agent was ever run against a repository you did not write. Pay particular attention to MCP server definitions and any steering or rules files that load automatically — those are the entries that convert into behaviour or processes.
Treat the audit as required, not optional, on shared or build machines. A developer workstation that has cloned untrusted code and a CI runner with an agent configured are both in scope, and the second is unlikely to have anyone reviewing a home-directory config.
Stop relying on the untrusted-workspace toggle as an agent boundary. Until the enforcement model changes, review unfamiliar repositories without an agent attached, or open them in a container or VM whose home directory is disposable.
Check version inventory across the fleet rather than per-developer. IDE updates are user-initiated in most organisations; an 8.8 in a developer tool with a persistence primitive is worth a managed rollout.
Extend the same question to your other agentic IDEs. The defect is architectural, not Amazon-specific. Ask of each: can repository content cause a write outside the workspace, and is that prevented by a path list or by instruction provenance?

A CVE in a developer tool used to mean an attacker needed you to run something. In an agentic IDE the tool runs continuously on your behalf, and the file that configures it is reachable by the content it reads. Until write authority is scoped by where the instruction came from, each new advisory will keep naming a path the last fix did not anticipate.

Sources: