A critical security vulnerability in AWS Kiro, Amazon’s agentic coding Integrated Development Environment (IDE), allowed for remote code execution (RCE) on a developer’s machine through seemingly innocuous hidden text embedded within a web page. This sophisticated attack vector, uncovered by cybersecurity research firm Intezer in collaboration with Kodem Security, demonstrated how Kiro could be coerced into rewriting its own critical configuration files, subsequently executing arbitrary attacker-controlled code without requiring explicit user approval. The incident highlights the complex security challenges inherent in the burgeoning field of AI-powered developer tools, particularly those designed with extensive autonomous capabilities.
The core of the vulnerability exploited Kiro’s ability to process external web content and its inherent trust in modifying its internal configuration. Researchers found that a simple request to Kiro, such as asking it to summarize an online document or fetch a URL, could inadvertently trigger the malicious chain of events. An attacker could embed specially crafted instructions within one-pixel white text on a white background – effectively invisible to the human eye – on an otherwise legitimate web page, like API documentation. When Kiro ingested this page, it interpreted the hidden instructions as valid tasks. These instructions directed Kiro to write a malicious entry into its ~/.kiro/settings/mcp.json file, which is responsible for listing and launching Model Context Protocol (MCP) servers and their associated commands. Crucially, Kiro automatically reloaded this file upon modification, launching the newly registered malicious server with the developer’s privileges, thus achieving remote code execution.
The Mechanism of Compromise: Bypassing the Human-in-the-Loop
AWS Kiro’s security model was designed around a "human-in-the-loop" principle, where developers are expected to review and explicitly "allow" any potentially risky operations, such as running shell commands, fetching URLs, or editing files. This approval step was intended to serve as the primary security boundary. However, the discovered flaw effectively circumvented this critical safeguard. Intezer and Kodem Security’s research revealed that Kiro’s fsWrite tool, responsible for file system operations, could write to mcp.json without requiring prior approval. Furthermore, Kiro’s automatic reload mechanism for mcp.json meant that any changes to this file were immediately acted upon, regardless of whether a developer had reviewed or sanctioned them.
The mcp.json file dictates which external tools Kiro loads and the precise commands used to initiate them. By manipulating this file, an attacker could register a new MCP server whose "start command" was, in reality, arbitrary code. The moment Kiro reloaded the modified mcp.json, this malicious command would execute on the host system with the same privileges as the logged-in developer. This level of access is highly dangerous, potentially allowing an attacker to steal sensitive credentials, exfiltrate source code, establish persistent backdoors, or pivot into other internal systems accessible from the compromised machine.
Intezer’s proof of concept (PoC) demonstrated this by planting its instructions in color:#fff;font-size:1px text on an API documentation page. When a developer instructed Kiro to process this page (e.g., summarize it), Kiro would read the hidden block as a setup task, write the malicious server configuration into mcp.json, and then automatically reload its configuration. Within seconds, the rogue server would initiate, and the attacker’s code would be running. In their controlled demo, the payload merely phoned home with basic machine information (hostname, username, platform) every ten seconds, sufficient to prove execution without causing harm. The researchers meticulously kept their callback pointed at localhost to ensure no actual Kiro users were exposed during their testing. They acknowledged the non-deterministic nature of AI models, noting that Kiro might occasionally summarize a page and overlook the hidden block. However, their testing showed successful execution within one or two attempts, emphasizing that even a single successful bypass is sufficient for compromise.
Adding to the complexity, Kiro did, in some instances, display a pop-up warning that the MCP configuration had changed and asked for approval. Yet, this warning proved to be a facade; the configuration reloaded regardless of the developer’s response, rendering the "approval" step utterly ineffective. The only action genuinely approved by the developer in the attack chain was the initial, seemingly benign, act of fetching a URL.
A Recurring Pattern: Historical Vulnerabilities in Kiro
This vulnerability was not an isolated incident but rather a re-emergence of a similar class of flaws that had plagued Kiro since its inception. Just months after Kiro’s initial release in July 2025, Johann Rehberger of Embrace The Red identified an almost identical "mcp.json write-to-execution" vector. His research, published shortly after Kiro’s launch, demonstrated that a prompt injection could inject custom code directly into an MCP settings file, which would then execute upon saving. Rehberger also highlighted a second critical path: writing to .vscode/settings.json to allowlist shell commands.
AWS responded to Rehberger’s findings with Kiro version 0.1.42, which introduced an approval prompt for .vscode/settings.json writes, but with a critical caveat: this prompt was only active in "Supervised mode." Kiro’s default "Autopilot mode" continued to write to the file autonomously, leaving a significant attack surface open. Intezer’s 2026 exploit chain leveraged precisely this oversight in Autopilot mode, underscoring the limitations of partial security fixes. No CVE was assigned to Rehberger’s initial findings, indicating a potential underestimation of the severity or scope by AWS at the time.
Further cementing this pattern, cybersecurity firm Cymulate also reported a related vulnerability where Kiro would auto-execute code written to .vscode/tasks.json when a folder was opened. This particular flaw prompted AWS to assign CVE-2026-10591, which received a high severity rating of 8.8 under CVSS 3.1 and 8.6 under CVSS 4.0. The issue was subsequently addressed in the Kiro 0.11 series. These successive discoveries painted a clear picture of a fundamental design flaw: Kiro’s undue trust in its own AI model’s judgment when interacting with sensitive configuration files.
Intezer’s mcp.json chain was still exploitable on Kiro versions 0.9.2 (macOS) and 0.10.16 (Ubuntu) when they reported it in February 2026. AWS confirmed the fix had been shipped in its latest release by April 2026, with researchers independently verifying the patch in v0.11.130.
AWS’s Remediation and Evolving Security Posture
In response to Intezer’s findings and the persistent nature of these vulnerabilities, AWS implemented a more robust, platform-level security control. The new approach involved moving the critical security checks out of the model’s discretion and into the underlying platform. Kiro now explicitly marks sensitive files and directories, such as mcp.json, .vscode/tasks.json, and the entire .git directory, as "protected paths." Writes to any of these protected paths now require explicit, non-bypassable approval from the developer, regardless of the operating mode (Autopilot or Supervised). This significant policy shift is clearly articulated in Kiro’s documentation, which states: "Supervised mode is a code review workflow, not a security control."
The subsequent Kiro 1.0 release further solidified this principle by introducing a comprehensive capability-based permissions model. This model ensures that developers are prompted for consent for any action or capability that has not been explicitly pre-approved, drastically reducing the attack surface. This combination of protected paths and granular permissions effectively closed the attack vector exploited by Intezer; confirmed testing showed that the attack failed in v0.11.130, and unlike the 2025 fix, the protected-paths check is enforced in both Autopilot and Supervised modes.
Intezer reported the flaw through the HackerOne bug bounty program on February 11, 2026. AWS acknowledged the report and, by April 3, stated that the fix had been deployed in its latest release, although a specific version number was not publicly named by AWS. Intezer researchers confirmed the patch in v0.11.130. As of July 21, 2026, The Hacker News found no CVE assigned to this specific finding in the National Vulnerability Database, nor did AWS publish a complete list of all affected builds. Intezer reported no evidence of in-the-wild exploitation, and their testing focused solely on the Kiro IDE, without establishing whether the separate Kiro CLI or Web builds shared the same vulnerability.
Current Kiro builds are on the 1.0.x line, with 1.0.165 being the latest version as of July 21, 2026. All users on older versions are strongly advised to update their Kiro installations from the official downloads page (kiro.dev/downloads/) to ensure they are protected against these and other patched vulnerabilities.
Broader Implications for AI-Powered Development Tools
The recurring nature of these vulnerabilities in AWS Kiro underscores a critical, industry-wide challenge facing the development of AI-powered coding tools. Over roughly a year, three distinct research efforts independently identified the same fundamental vulnerability pattern in Kiro: an AI agent autonomously modifying files that directly dictate its execution capabilities, often bypassing intended security controls.
Kiro is not unique in this regard. In December 2025, a comprehensive study cataloged over 30 similar flaws across various prominent AI coding tools, including Cursor and GitHub Copilot. These vulnerabilities frequently transformed legitimate editor functionalities into prompt-injection pathways, leading to remote code execution or unauthorized data exfiltration. The common thread among these incidents is the inherent difficulty in securing AI agents that process untrusted external input and possess broad system access. The "prompt injection" paradigm, where malicious instructions are subtly woven into legitimate inputs, presents a formidable challenge to traditional security models.
The current fixes implemented by AWS and other vendors universally point to a crucial lesson: effective security controls for AI agents must reside at the platform level. These controls must be enforced rigorously across all operational modes and must be inherently resistant to manipulation by the AI model itself, even if the model is "talked into" performing a malicious action. Relying solely on the AI’s judgment or on user approval that can be bypassed proves insufficient.
As more of the software development workflow becomes augmented or even automated by AI agents that interact with the open web and execute code, the paradigm of "a human in the loop" needs re-evaluation. For this control to be truly effective, the human must be presented with the actual critical step requiring approval, not a superficial or misleading one. Furthermore, the underlying platform must maintain an unyielding security perimeter, enforcing rules and permissions regardless of what the AI model has been instructed or persuaded to do. The Kiro incidents serve as a stark reminder that the integration of AI into critical development infrastructure demands a proactive, platform-centric approach to security, ensuring that the convenience of AI does not come at the cost of fundamental system integrity.
