Agent security incidents, January to June 2026: untrusted input reaching a shell

Most of the AI agent security incidents documented between January and June 2026 have a mundane cause. A piece of text that an attacker could influence ended up in a place where it was treated as a command, or a tool was exposed without authentication, or a look-alike package was installed in place of the real one. None of that requires a model to misbehave. It requires the plumbing around the model to trust input it should not.

This matters because the plumbing is what businesses are buying and building: the connectors, tool servers and registries that let an agent read a file, query a database or call an API. This post walks through the January to June 2026 record as documented by the Cloud Security Alliance (CSA), AuthZed, Wiz and The Hacker News, and what it implies for how agents should be deployed. It covers what we could confirm from public sources through the end of June; it is not a complete count of the year.

The headline case: STDIO and "execute-first, validate-never"

In April 2026, OX Security published research it titled "The Mother of All AI Supply Chains." The CSA's summary describes a remote code execution issue in the way Anthropic's MCP SDKs handle the STDIO transport: any process command passed to that interface executes on the host, whether or not it launches a valid MCP server ^[1]. The affected SDKs are the officially supported Python, TypeScript, Java and Rust ones ^[1].

The scale figures are OX's, as relayed by the CSA, and the CSA notes they are likely a lower bound: about 150 million downloads, more than 7,000 publicly accessible servers, and up to 200,000 vulnerable instances ^[1]. OX reported 10 or more critical or high-severity CVEs from more than 30 responsible disclosures. Named examples include CVE-2026-30615 in Windsurf, which the note rates the most severe zero-click case, and CVE-2026-40933 in Flowise, scored CVSS 10.0 ^[1].

The governance question is as interesting as the technical one. According to the CSA, Anthropic confirmed during coordinated disclosure in January 2026 that the behavior was intentional and declined to change the protocol architecture, taking the position that input sanitization is the developer's responsibility. Nine days after OX's first contact, Anthropic updated its SECURITY.md to say STDIO adapters should be used with caution, with no change to SDK architecture. OX publicly disputed that framing ^[1]. Whichever side one takes, the practical result is the same: the safe use of these SDKs sits with the people integrating them.

The rest of the 2026 record

AuthZed's running timeline, last updated May 30, 2026, lists the other 2026 incidents it tracked. They are summarized below ^[3].

Read the "What happened" column and the pattern is plain. Three of the four rows are input reaching a command execution path or an endpoint with no authentication check. The fourth is a supply-chain impersonation. The CSA's May note adds that the MCP specification has no native defenses against tool poisoning, rug pulls or cross-server tool shadowing, and that its OAuth 2.1 authorization is optional, so many servers run with no authentication at all ^[2].

The registry problem deserves its own mention. In OX's test, 9 of 11 MCP registries accepted a benign proof-of-concept submission without review ^[1]. If a registry will list a harmless test entry unchecked, it will list a malicious one.

May and June 2026

AuthZed's timeline has no entries after April, so for later months we used primary research and trade-press coverage of it. Three June disclosures stand out.

• Amazon Q Developer (Wiz, June 26). Wiz reported that the Amazon Q Developer extension for VS Code automatically loaded MCP server configurations from .amazonq/mcp.json in a workspace when a folder was opened, with no consent prompt or workspace trust check, and that the spawned processes inherited the user's full environment, including cloud credentials and SSH agent sockets. The issue is tracked as CVE-2026-12957 and affected language server versions earlier than 1.65.0. Per Wiz's timeline, it was reported on April 20, fixed on May 12, assigned a CVE on June 23 and disclosed publicly on June 26 ^[4].

• GuardFall (Adversa AI, reported June 30). Adversa tested 11 open-source coding and computer-use agents and found a shell-quoting bypass worked against 10; Continue was the only one that defended against it. Filters that check commands as plain text miss that bash rewrites the text before running it. The report notes an attack also needs the agent to run commands without human approval, and that no single CVE or vendor patch was reported ^[5].

• Poisoned MCP tool descriptions (Microsoft, reported June 30). Microsoft Incident Response and Defender researchers described how changing a third-party tool's description can make an agent quietly send company data to an outside party. Microsoft framed it as a trust gap from connecting outside tools, not a bug in Copilot, and no patch or CVE was mentioned ^[6].

We did not find enough well-sourced July and August incidents to include, so this post stops at June.

What this means for how agents are deployed

The CSA notes give a consistent set of recommendations. The most useful ones for a business deploying agents today are these ^[1][2]:

• Inventory every tool server. That includes the ones embedded in developer tools such as IDEs and desktop assistants, which often ship with their own MCP configuration ^[2].

• Treat every command parameter as untrusted. The CSA's phrasing is to treat every command parameter as an untrusted execution surface, and to restrict server registration to a reviewed allowlist kept outside model-controlled context ^[1].

• Sandbox STDIO servers. Run them in isolated containers without host credentials, and block or log shell execution at the container boundary ^[2].

• Use per-server, least-privilege credentials. Mediate cross-server actions through an explicit policy layer rather than relying on the agent's own judgment ^[2].

• Set procurement rules for public tool servers. Pin versions, require provenance, and alert when a tool definition changes ^[2].

• Do not rely on SDK updates alone. The CSA states this directly, given Anthropic's position that the STDIO behavior is intended ^[1].

Limits of this record

Three caveats keep this analysis honest. First, coverage after April depends on single research write-ups and trade-press summaries rather than a maintained incident database, and some items (GuardFall, tool-description poisoning) are research findings rather than confirmed in-the-wild compromises. Second, the scale numbers in the headline case are OX's estimates, not independently measured counts; "up to 200,000 vulnerable instances" is a potential, not a confirmed number of compromised systems ^[1]. Third, AuthZed's timeline gives only month and year for each entry and stops at its May 30 update, so it is a sample of public incidents rather than a complete count ^[3]. Nothing here should be read as a measure of how often agents are attacked in practice, only of what has been publicly documented.

Practical implication

An agent is only as safe as the least-reviewed tool server it can call. Before expanding what an agent is allowed to do, list every connector it uses, give each its own minimal credentials, and run anything that executes commands inside a sandbox.