MCP Attacks Hit Developer IDEs: Amazon Q Flaw and Agentjacking

server rack free stock image for MCPwatch editorial use
Topic image: server rack free stock image for MCPwatch editorial use.

The Threat Shifts: MCP Vulnerabilities Now Target Developer Workstations Directly

Two disclosures in late June 2026 crystallize a shift in the MCP threat landscape: the attack surface has moved from server-side SSRF and path-traversal bugs to developer workstations themselves, where AI coding assistants auto-execute MCP configurations and process tool output without the skepticism those outputs deserve.

On June 26, 2026, Wiz Research published details of CVE-2026-12957 — a high-severity vulnerability (CVSS 8.5) in the Amazon Q Developer IDE extension that automatically loaded and executed MCP server configurations from workspace files without user consent. Opening a malicious repository was sufficient for an attacker to execute arbitrary code and exfiltrate AWS credentials, API keys, and SSH agent sockets.

Twelve days earlier, on June 12, 2026, Tenet Security disclosed Agentjacking — an attack class that weaponizes the MCP error-reporting channel in AI coding agents. By injecting fake Sentry error reports containing malicious instructions, attackers achieved an 85% exploitation success rate across Claude Code, Cursor, and Codex in controlled testing, with at least 2,388 organizations confirmed as injectable targets.

Together, these disclosures demonstrate that MCP is no longer just a server-hardening problem. The protocol’s trust model — where AI agents auto-discover, auto-connect, and auto-process tool responses — creates a direct path from untrusted content to code execution on developer machines.

CVE-2026-12957: Amazon Q Developer Auto-Executes MCP Configs

What happened: The Amazon Q Developer extension for VS Code, JetBrains, Eclipse, and Visual Studio automatically loaded and executed MCP server configurations found in .amazon/q/mcp_servers.json (or equivalent workspace-level settings) whenever a developer opened a project folder. No explicit user consent was required.

Impact: A malicious repository could specify an MCP server pointing to an attacker-controlled endpoint. The moment a developer opened the repo, Amazon Q would connect to that server, granting it access to the developer’s local environment — including AWS credentials (~/.aws/credentials), cloud CLI tokens, API keys, and SSH agent sockets.

Root cause: The extension treated repository-level MCP configurations as trusted by default, reflecting a broader protocol design assumption that local MCP configs are inherently safe. This is the same trust boundary that DuneSlide exploited (CVE-2026-50548/50549) in Cursor’s sandbox, and it is the trust boundary that the NSA’s May 2026 CSI on MCP security specifically flagged as a gap.

Fix: Amazon patched CVE-2026-12957 and CVE-2026-12958 (a related symlink-handling issue) starting with Language Servers for AWS version 1.65.0, with 1.69.0 as the recommended minimum. Wiz reported the vulnerability on April 20, 2026; Amazon patched on May 12; public disclosure followed on June 26.

Operator Action Items for CVE-2026-12957

  • Update Amazon Q Developer extensions to Language Servers for AWS ≥ 1.69.0 across all IDEs (VS Code, JetBrains, Eclipse, Visual Studio).
  • Audit .amazon/q/mcp_servers.json and similar MCP config files in repositories for unexpected entries.
  • Review AWS credential scope: the MCP server that auto-executed had the same access as the developer’s local AWS profile. Rotate any credentials that may have been exposed in open-source repos or forks.
  • Apply the MCP server security checklist principle of explicit consent: never auto-connect to MCP servers discovered in untrusted workspace files.

Agentjacking: Fake Sentry Errors Hijack AI Coding Agents

What happened: Tenet Security disclosed an attack class they term Agentjacking. The attack exploits the Sentry MCP server, which AI coding agents (Claude Code, Cursor, Codex) use to retrieve and resolve errors. An attacker crafts a fake Sentry error report containing malicious instructions disguised as remediation steps. When a developer asks their AI agent to “fix unresolved Sentry issues,” the agent queries the Sentry MCP, receives the fake error, and executes the embedded commands.

Why it works: The attack exploits three MCP trust boundaries simultaneously:

  1. Agent trust in MCP tool output: AI coding agents treat MCP tool responses as authoritative data, not as potentially adversarial content. They do not distinguish between a legitimate Sentry error and a crafted one.
  2. Agent capability to execute: The same agents that read errors also have terminal access, file write permissions, and network egress — all the capabilities needed to install backdoors or exfiltrate data.
  3. MCP channel as attack vector: The Sentry MCP server becomes an injection channel. No server compromise is required; the attacker only needs a valid Sentry DSN (project key) to inject fake events, and 2,388 organizations had injectable DSNs publicly exposed.

Scale: Tenet Security measured an 85% exploitation success rate across major AI coding assistants in controlled tests. The Cloud Security Alliance published an independent research note confirming the attack class and its implications for MCP supply chain trust.

Operator Action Items for Agentjacking

  • Restrict Sentry MCP server capabilities to read-only error listing. Remove any write, command, or code-execution tools from your Sentry MCP configuration.
  • Audit Sentry DSN exposure: search code repositories and public-facing JavaScript for hardcoded Sentry DSNs. Rotate any DSNs found in public repos.
  • Implement MCP authorization controls: scope each MCP server to the minimum permissions required, and require human confirmation before agents execute shell commands or file modifications based on MCP tool output.
  • Consider the NSA CSI recommendation: treat MCP tool responses as untrusted input to the agent, requiring validation before any action with side effects.

Additional New MCP CVEs: Developer Tools Under Pressure

CVE-2026-53766: chrome-devtools-mcp Path Traversal (CVSS 6.1)

The chrome-devtools-mcp package, which lets AI agents control and inspect a live Chrome browser via MCP, contains a directory traversal vulnerability in its validatePath() function. From version 0.24.0 until 1.1.0, the function validated paths by checking whether path.resolve(filePath) textually starts with a workspace root string — but did not resolve symbolic links first. An attacker controlling an MCP response could create a symlink pointing outside the workspace, and the validation would still pass, allowing the agent to read arbitrary files and send their contents to a web page.

Fixed in version 1.1.0. This CVE illustrates the same pattern as CVE-2026-52830 (fast-mcp-telegram path traversal) that we covered last week: MCP server developers are not canonicalizing paths before validating boundaries.

OpenClaw MCP Gateway: Three CVEs in One Platform

OpenClaw, a personal AI assistant that bundles an MCP loopback interface for local inter-process communication, has disclosed three vulnerabilities in its MCP handling:

  • CVE-2026-53840 (High): Sensitive header leakage via cross-origin redirects in streamable-HTTP MCP servers. Operator-configured custom headers (API keys, bearer tokens, tenant-routing credentials) are forwarded during cross-origin HTTP redirects, enabling credential exfiltration if an attacker controls or compromises a configured MCP endpoint. Fixed in OpenClaw 2026.5.12.
  • CVE-2026-53820 (Medium): Exec denylist bypass in the MCP loopback session-spawn path. Authenticated callers could bypass intended command restrictions. Fixed in OpenClaw 2026.5.12.
  • CVE-2026-53818 (High): Authorization bypass in the MCP loopback feature. Non-owner callers could skip owner-only tool policies and before-tool-call hooks. Fixed in OpenClaw 2026.4.24.

These three CVEs — header leakage, denylist bypass, and authorization bypass — represent a full stack of MCP gateway trust failures: credential exposure at the transport layer, execution control bypass, and policy circumvention at the authorization layer. Operators running OpenClaw should update to version 2026.5.12 or later immediately and rotate any MCP-specific API keys or bearer tokens that may have been forwarded to untrusted endpoints.

CVE-2026-34742: Go MCP SDK DNS Rebinding (CVSS 8.1)

The official Go MCP SDK, prior to version 1.4.0, did not enable DNS rebinding protection by default for HTTP-based servers. An attacker could register a domain that resolves to localhost, connect via MCP, and then change the DNS record to an internal service — bypassing same-origin policy and sending requests to local MCP servers without authentication. Fixed in version 1.4.0. This is a protocol-level infrastructure vulnerability, not a single-server bug, and affects any deployment running the Go MCP SDK with HTTP transport on a network-reachable port.

Pattern: The Developer Workstation Is the New MCP Frontier

The common thread across these disclosures is trust in local contexts. Amazon Q trusted workspace MCP configs. Agentjacking trusts MCP tool output. chrome-devtools-mcp trusts symlinks. OpenClaw trusts loopback callers and MCP endpoint redirects. The Go SDK trusts DNS resolution.

This is exactly the pattern the NSA’s May 2026 CSI on MCP security warned about: MCP implementations consistently treat local-scope inputs — configs, tool responses, loopback requests, DNS resolution — as more trustworthy than they actually are. The attacker’s insight in each case was to exploit that trust boundary, turning a protocol designed for convenience into a direct path to the developer’s environment.

What MCPwatch Is Tracking

We are actively monitoring the following developments:

  • Amazon Q patch adoption: How many organizations have updated to Language Servers for AWS ≥ 1.69.0? Wiz reports that the vulnerability was exploitable for months before patching — credential rotation is essential even after the update.
  • Agentjacking countermeasures: The CSA research note recommends treating all MCP tool output as untrusted input. We expect MCP client implementations to add output validation layers; until then, operator-side controls are the primary defense.
  • chrome-devtools-mcp adoption: As one of the most-installed MCP servers for browser automation, its path traversal vulnerability has significant blast radius. Check your versions.
  • OpenClaw MCP gateway hardening: The combination of header leakage, denylist bypass, and authorization bypass suggests the MCP loopback feature was not security-reviewed before release. Operators should treat all MCP gateway features as potentially untrusted until independently audited.

Sources

  • Wiz Research: “Amazon Q Vulnerability: Compromise via MCP Auto-Execution” — wiz.io
  • AWS Security Bulletin: CVE-2026-12957 and CVE-2026-12958 — aws.amazon.com
  • Tenet Security / Hacker News: Agentjacking disclosure — thehackernews.com
  • Cloud Security Alliance: Research Note on Agentjacking — cloudsecurityalliance.org
  • NVD: CVE-2026-12957 — nvd.nist.gov
  • Snyk: CVE-2026-53766 (chrome-devtools-mcp) — snyk.io
  • NVD: CVE-2026-53840 (OpenClaw header leakage) — nvd.nist.gov
  • NVD: CVE-2026-53820 (OpenClaw denylist bypass) — nvd.nist.gov
  • NVD: CVE-2026-53818 (OpenClaw authorization bypass) — nvd.nist.gov
  • NVD: CVE-2026-34742 (Go MCP SDK DNS rebinding) — nvd.nist.gov
  • NSA AISC: “MCP: Security Design Considerations for AI-Driven Automation” (CSI, May 2026) — defense.gov

Leave a Comment