What Happened
AWS's Kiro IDE had a vulnerability that allowed attackers to rewrite its configuration file and execute code without triggering approval prompts. Intezer's research team found that Kiro could modify its own mcp.json configuration using its fsWrite tool, then automatically reload the altered config. An attacker serving a malicious web page could exploit this to inject harmful Model Context Protocol (MCP) servers into a developer's environment. AWS has patched the issue, but no CVE was assigned.
Timeline
The exact discovery and disclosure timeline hasn't been published, but the sequence is important:
- Intezer identified that Kiro's
fsWritetool could modifymcp.jsonwithout user approval. - Researchers demonstrated that the IDE would automatically reload modified configurations.
- Attack vector confirmed: malicious web content could trigger the rewrite.
- AWS released a patch.
- No formal CVE tracking was initiated.
The lack of CVE assignment creates a gap in your vulnerability management process. If you're tracking IDE security through CVE feeds, you missed this one.
Which Controls Failed
Three layers broke down:
User approval bypass. Kiro's security model relied on developers clicking "approve" before the AI executed actions. However, the tool's own configuration management bypassed this gate. When Kiro wrote to its config file, no approval prompt appeared.
Configuration integrity checks. The IDE reloaded mcp.json automatically without validating the source of changes. There was no signature verification, change audit, or prompt asking, "are you sure you want to load this server definition?"
Least privilege violation. Kiro's fsWrite tool had blanket write access to its own configuration directory. The tool didn't need write access to mcp.json to function as an AI coding assistant, but it had it anyway.
What Standards Require
OWASP ASVS v4.0.3 Requirement 5.1.5 states applications must validate all untrusted file operations. Your IDE is an application. Configuration files are untrusted input when they can be modified by external content.
PCI DSS v4.0.1 Requirement 6.4.3 requires authorization for script execution in payment environments. If you're building payment systems with AI tools, those tools must enforce execution controls. Automatic config reloads that enable code execution fail this requirement.
ISO/IEC 27001:2022 Control 8.22 (segregation of duties) applies here. The component that writes files shouldn't be the same component that decides which MCP servers to trust. Kiro collapsed both roles into one tool.
NIST 800-53 Rev 5 CM-3 (Configuration Change Control) requires changes to configuration settings to go through an approval process. Automatic reloads of modified configs violate this control in any environment where you're trying to meet NIST requirements.
The pattern: every major framework assumes you'll validate configuration changes before acting on them. Kiro didn't.
Lessons and Action Items
1. Inventory your AI development tools' file system access
List every AI coding assistant, IDE plugin, and automation tool your team uses. For each one, document:
- Which directories it can write to
- Whether it can modify its own configuration
- What happens when configs change
If you don't know the answers, you can't assess the risk. Start with your most privileged developers' machines.
2. Implement config signing for development tools
Your CI/CD pipeline probably validates container signatures. Apply the same principle to IDE configurations. Tools like Sigstore can sign config files. Your IDE should reject unsigned or improperly signed mcp.json files.
This isn't theoretical. If you're subject to SOC 2 Type II audits, your auditor will ask how you prevent unauthorized changes to development tool configurations. "The IDE checks for user approval" isn't an adequate control when the IDE can bypass its own checks.
3. Separate config management from execution
Don't let the same component that writes configs also load them. Consider a development environment where:
- AI tools can suggest config changes
- A separate approval process (even just a git commit review) validates the change
- The IDE only loads configs from a trusted path
This mirrors how you handle production configs. Your deployment system doesn't let application code rewrite its own Kubernetes manifests. Apply that principle to development tools.
4. Track non-CVE security updates
AWS patched Kiro without assigning a CVE. Your vulnerability scanner missed it. Your compliance dashboard shows no new findings. But the risk was real.
Build a tracking system for:
- Vendor security advisories (even without CVEs)
- Research disclosures from firms like Intezer
- GitHub security advisories for tools you use
If you're only tracking CVEs, you're missing vendor-specific patches that don't enter the CVE system.
5. Test AI tool isolation
Run this test: can your AI coding assistant modify files outside its designated workspace? Can it alter system configs? Can it install MCP servers without your approval?
If you don't know, assume yes. Then test in a sandboxed environment. Tools like Bubblewrap or Firejail can restrict file system access. Your AI assistant doesn't need write access to ~/.config or equivalent directories.
6. Review MCP server trust models
Model Context Protocol servers extend AI tool capabilities. They're also an attack surface. Document:
- Which MCP servers your team uses
- Who approved each server
- Whether servers can be added without security review
Treat MCP servers like browser extensions: useful, but requiring explicit approval and periodic review.
The Broader Pattern
Kiro isn't alone. Similar approval-bypass issues have affected other AI coding tools. Tools designed to reduce friction (click fewer buttons, approve fewer actions) create security gaps. Your job is to add back the friction that matters while removing the friction that doesn't.
Ask this about every AI development tool: what's the worst thing it could do if an attacker could feed it malicious input? If the answer is "execute arbitrary code," you need platform-level controls that don't rely on the tool policing itself.
