Claude Code is an agentic coding tool. From 2.1.38 until 2.1.163, Claude Code's worktree handling allowed creation of worktrees named ".git" and navigation to worktrees outside the sandbox context, enabling git directory confusion attacks. By exploiting symlink manipulation and git fsmonitor execution during worktree operations, an attacker could overwrite files in the user's home directory (such as .zshenv), leading to code execution outside of seatbelt sandbox restrictions. Reliably exploiting this required the user to clone a malicious repository containing prompt injection content and run Claude Code against it. This vulnerability is fixed in 2.1.163.

CVE-2026-52870 is a missing authorization vulnerability (CWE-862) in Anthropic's official Model Context Protocol Python SDK that allows any client on a shared server to enumerate, read, and cancel tasks belonging to other clients.

The default request handlers registered by the experimental enabletasks() helper operate on task IDs alone without checking caller identity, storing active workflows in a single global server store.

The vulnerability was patched in mcp version 1.27.2, and operators of multi-client MCP gateways are advised to upgrade immediately.

Claude Code is an agentic coding tool. From 2.1.59 until 2.1.128, the Claude Code /copy command wrote responses to a hardcoded, predictable path (/tmp/claude/response.md) without UID isolation, randomness, or symlink protection. The file was created world-readable (0644) in a world-traversable directory (0755), allowing any local user to read a privileged user's Claude response, which could contain secrets or credentials. Additionally, because the path was static and predictable, a local attacker could pre-create the directory and plant a symlink at the expected file path, causing the privileged process to follow the symlink and overwrite an attacker-chosen file with the response text. Exploiting this required a local unprivileged user on the same system and a privileged user to run the /copy command. This vulnerability is fixed in 2.1.128.

Anthropic Claude Desktop Cowork VM image handling (confirmed across v1.1348.0 through v1.2278.0, including v1.1348.0, v1.1617.0, and v1.2278.0) validates only file presence and a version marker string before booting rootfs.img, but does not verify image content integrity at time-of-use. A local attacker with unprivileged code execution as the victim macOS user can modify the VM root filesystem image and have it trusted on subsequent Cowork VM boots, enabling persistent arbitrary code execution in the VM and access to host-mounted directories. The estimated CWE mapping is CWE-353 (Missing Support for Integrity Check).

Because the hostname huggingface.co was pre-approved as a bare hostname for the WebFetch tool, any path on that domain—including attacker-controlled model repositories—was auto-approved without a permission prompt or being subject to --allowedTools restrictions. An attacker able to inject untrusted content into a Claude Code context could direct it to issue WebFetch requests against attacker-controlled repository files (e.g. /resolve/main/config.json), which HuggingFace counts as downloads server-side, creating a covert out-of-band channel for encoding and exfiltrating data Claude can access such as files, environment variables, or command output. Reliably exploiting this required the ability to add untrusted content into a Claude Code context window. Users on standard Claude Code auto-update have received this fix already; users performing manual updates are advised to update to the latest version.

Thank you to hackerone.com/novee for reporting this issue.

The Claude Desktop app gives you Claude Code with a graphical interface built for running multiple sessions side by side. Prior to 1.3834.0, the CoworkVMService component in Claude Desktop for Windows ran as SYSTEM and did not validate whether the VM bundle directory was a real directory or an NTFS directory junction before creating files within it. A local non-elevated user could replace the user-writable VM bundle directory with a directory junction pointing to an attacker-chosen location, causing the service to create a SYSTEM-owned file in an arbitrary directory. This could be leveraged for local privilege escalation. This vulnerability is fixed in 1.3834.0.

The Claude Desktop app gives you Claude Code with a graphical interface built for running multiple sessions side by side. From 1.2581.0 to before 1.4304.0, Claude Desktop's SSH remote development feature verified only whether a hostname existed in ~/.ssh/knownhosts without comparing the server's presented host key against the stored key. This allowed a network-positioned attacker to present an arbitrary SSH host key and have the connection silently accepted, enabling a man-in-the-middle attack on remote development sessions. Successful exploitation required the attacker to be in a network position to intercept SSH traffic (e.g., via ARP spoofing, rogue Wi-Fi, or DNS poisoning) and the target hostname to already have an entry in the victim's knownhosts file. This vulnerability is fixed in 1.4304.0.

Claude SDK for TypeScript provides access to the Claude API from server-side TypeScript or JavaScript applications. From version 0.79.0 to before version 0.91.1, the BetaLocalFilesystemMemoryTool in the Anthropic TypeScript SDK created memory files and directories using the Node.js default modes (0o666 for files, 0o777 for directories), leaving them world-readable on systems with a standard umask and world-writable in environments with a permissive umask such as many Docker base images. A local attacker on a shared host could read persisted agent state, and in containerized deployments could modify memory files to influence subsequent model behavior. This issue has been patched in version 0.91.1.

Claude Code used the git worktree commondir file when determining folder trust but did not validate its contents. By crafting a repository with a commondir file pointing to a path the victim had previously trusted, an attacker could bypass the trust dialog and immediately execute malicious hooks defined in .claude/settings.json. Exploiting this required the victim to clone a malicious repository and run Claude Code within it, and for the attacker to know or guess a path the victim had already trusted.

Users on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to the latest version.

Claude Code thanks hackerone.com/masatoanzai for reporting this issue.

Claude Code is an agentic coding tool. Prior to version 2.1.64, Claude Code's sandbox did not prevent sandboxed processes from creating symlinks pointing to locations outside the workspace. When Claude Code subsequently wrote to a path within such a symlink, its unsandboxed process followed the symlink and wrote to the target location outside the workspace without prompting the user for confirmation. This allowed a sandbox escape where neither the sandboxed command nor the unsandboxed app could independently write outside the workspace, but their combination could write to arbitrary locations, potentially leading to code execution outside the sandbox. Reliably exploiting this required the ability to add untrusted content into a Claude Code context window to trigger sandboxed code execution via prompt injection. Users on standard Claude Code auto-update have received this fix automatically. Users performing manual updates are advised to update to version 2.1.64 or later.

Claude Code is an agentic coding tool. In versions prior to 2.1.75 on Windows, Claude Code loaded the system-wide default configuration from C:\ProgramData\ClaudeCode\managed-settings.json without validating directory ownership or access permissions. Because the ProgramData directory is writable by non-administrative users by default and the ClaudeCode subdirectory was not pre-created or access-restricted, a low-privileged local user could create this directory and place a malicious configuration file that would be automatically loaded for any user launching Claude Code on the same machine. Exploiting this would have required a shared multi-user Windows system and a victim user to launch Claude Code after the malicious configuration was placed. This issue has been fixed on version 2.1.75.

Rejected reason: This CVE ID has been rejected by its CVE Numbering Authority (CNA). It was determined that the -p flag behavior is documented in Anthropic's claude -h output with an explicit warning that non-interactive mode should only be used in trusted directories, making this intended and described behavior rather than a vulnerability.

Rejected reason: This CVE ID has been rejected by the its CVE Numbering Authority (CNA). It was determined that the attack requires an attacker to already control arbitrary environment variables, a level of access they consider functionally equivalent to code execution and outside the threat model of CLI tools.

Claude SDK for TypeScript provides access to the Claude API from server-side TypeScript or JavaScript applications. From version 0.79.0 to before version 0.81.0, the local filesystem memory tool in the Anthropic TypeScript SDK validated model-supplied paths using a string prefix check that did not append a trailing path separator. A model steered by prompt injection could supply a crafted path that resolved to a sibling directory sharing the memory root's name as a prefix, allowing reads and writes outside the sandboxed memory directory. This issue has been patched in version 0.81.0.

The Claude SDK for Python provides access to the Claude API from Python applications. From version 0.86.0 to before version 0.87.0, the local filesystem memory tool in the Anthropic Python SDK created memory files with mode 0o666, leaving them world-readable on systems with a standard umask and world-writable in environments with a permissive umask such as many Docker base images. A local attacker on a shared host could read persisted agent state, and in containerized deployments could modify memory files to influence subsequent model behavior. Both the synchronous and asynchronous memory tool implementations were affected. This issue has been patched in version 0.87.0.

The async local filesystem memory tool in the Anthropic Python SDK validated that model-supplied paths resolved inside the sandboxed memory directory, but then returned the unresolved path for subsequent file operations. A local attacker able to write to the memory directory could retarget a symlink between validation and use, causing reads or writes to escape the sandbox. The synchronous memory tool implementation was not affected.

Users on the affected versions are advised to update to the latest version.

Claude SDK for Python thanks hackerone.com/kasthelord for reporting this issue!

Uncontrolled search path elements in Anthropic Claude for Windows installer (Claude Setup.exe) versions prior to 1.1.3363 allow local privilege escalation via DLL search-order hijacking. The installer loads DLLs (e.g., profapi.dll) from its own directory after UAC elevation, enabling arbitrary code execution if a malicious DLL is planted alongside the installer.

CVE-2026-33068 (CVSS 7.7 HIGH) affects Anthropic's Claude Code, an AI-powered coding assistant that operates as a CLI tool with file system access, command execution, and network capabilities. The vulnerability is a configuration loading order defect. Claude Code supports a .claude/settings.json file in repositories, which can include a bypassPermissions field to pre-approve specific operations. The bug: repository-level settings were resolved before the workspace trust confirmation dialog was presented to the user. A malicious repository could include a settings file that grants itself elevated permissions, and those permissions would take effect before the user was asked whether to trust the workspace. CWE-807: Reliance on Untrusted Inputs in a Security Decision. This is notable because it is a very traditional software engineering vulnerability in an AI tool. Not a prompt injection, not an adversarial ML attack. A settings loading order bug. The security boundary between "untrusted code" and "trusted workspace" was broken by the sequence in which configuration files were processed. Fixed in Claude Code 2.1.53. If you use Claude Code, verify your version with claude --version .

Full advisory: https://raxe.ai/labs/advisories/RAXE-2026-040

CVE-2026-33068 is a configuration loading order defect in Anthropic's Claude Code CLI tool (versions prior to 2.1.53). A malicious .claude/settings.json file in a repository can bypass the workspace trust confirmation dialog by exploiting the order in which settings are resolved. The mechanism: Claude Code supports a bypassPermissions field in settings files. This is a legitimate, documented feature intended for trusted workspaces. The vulnerability is that repository-level settings ( .claude/settings.json ) are loaded and resolved before the workspace trust dialog is presented to the user. A malicious repository can include a settings file with bypassPermissions entries, and those permissions are applied before the user has an opportunity to review and approve the workspace. This is CWE-807: Reliance on Untrusted Inputs in a Security Decision. The trust decision (whether to grant elevated permissions) depends on inputs from the entity being evaluated (the repository). The security boundary between "untrusted repository" and "trusted workspace" is bridged by the settings loading order. The fix in Claude Code 2.1.53 changes the loading order so that the trust dialog is presented before repository-level settings are resolved. Worth noting: bypassPermissions is not a hidden feature or a misconfiguration. It is documented and useful for legitimate workflows. The bug is purely in the loading order.

Claude Code is an agentic coding tool. Versions prior to 2.1.53 resolved the permission mode from settings files, including the repo-controlled .claude/settings.json, before determining whether to display the workspace trust confirmation dialog. A malicious repository could set permissions.defaultMode to bypassPermissions in its committed .claude/settings.json, causing the trust dialog to be silently skipped on first open. This allowed a user to be placed into a permissive mode without seeing the trust confirmation prompt, making it easier for an attacker-controlled repository to gain tool execution without explicit user consent. This issue has been patched in version 2.1.53.

Okay so before I start, let me tell you why I even did this. There is a lot of content going around about AI agent security that mixes real verified incidents with half-baked stats and some things that just cannot be traced back to any actual source. I went through all of it properly. Primary sources, CVE records, actual research papers. Let me tell you what I found.

Single agent attacks first, because you need this baseline

Black Hat USA 2025 — Zenity Labs did a live demonstration where they showed working exploits against Microsoft Copilot, ChatGPT, Salesforce Einstein, and Google Gemini in the same session. One demo had a crafted email triggering ChatGPT to hand over access to a connected Google Drive. Copilot Studio was leaking CRM databases. This is confirmed, sourced, happened. The only thing I could not verify was the specific "3,000 agents actively leaking" number that keeps getting quoted. The demos are real, that stat is floating without a clean source.

CVE-2025-32711, which people are calling EchoLeak — this one is exactly as bad as described. Aim Security found that receiving a single crafted email in Microsoft 365 Copilot was enough to trigger automatic data exfiltration. No clicks required. CVSS 9.3, confirmed, paper is on arXiv. This is clean and verified.

Slack AI in August 2024 — PromptArmor showed that Slack's AI assistant could be manipulated through indirect prompt injection to surface content from private channels the attacker had no access to. You put a crafted message in a public channel and Slack's own AI becomes the tool that reads private conversations. Fully verified.

The one that should genuinely worry enterprise people — a threat group compromised one chat agent integration, specifically the Drift chatbot in Salesloft, and cascaded that into Salesforce, Google Workspace, Slack, Amazon S3, and Azure environments across 700 plus organizations. One agent, one integration, 700 organizations. This is confirmed by Obsidian Security research.

Anthropic confirmed directly in November 2025 that a Chinese state-sponsored group used Claude Code to attempt infiltration of roughly 30 global targets across tech, finance, chemical manufacturing, and government. Succeeded in some cases. What made it notable was that 80 to 90 percent of the tactical operations were executed by the AI agents themselves with minimal human involvement. First documented large-scale cyberattack of that kind.

Browser Use agent, CVE-2025-47241, CVSS 9.3 — confirmed. But there is a technical correction worth noting. Some summaries describe this as prompt injection combined with URL manipulation. It is actually a URL parsing bypass where an attacker embeds a whitelisted domain in the userinfo portion of a URL. Sounds similar but if you are writing a mitigation, the difference matters.

The Adversa AI report about Amazon Q, Azure AI, OmniGPT, and ElizaOS failing across model, infrastructure, and oversight layers — I could not independently surface this report from primary sources. The broader pattern it describes is consistent with what other 2025 research shows, but do not cite that specific stat in anything formal until you have traced it to the actual document.

Why multi-agent is a completely different problem

Single agent security is at least a bounded problem. Rate limiting, input validation, output filtering — hard to do right but you know what you are dealing with.

Multi-agent changes the nature of the problem. The reason is simple and a little uncomfortable. Agents trust each other by default. When your researcher agent passes output to your writer agent, the writer treats that as a legitimate instruction. No verification, no signing, nothing. Agent A's output is literally Agent B's instruction. So if you compromise A, you get B, C, and the database automatically without touching them.

There is peer-reviewed research on this from 2025 that was not in the original material circulating. CrewAI running on GPT-4o was successfully manipulated into exfiltrating private user data in 65 percent of tested scenarios. The Magentic-One orchestrator executed arbitrary malicious code 97 percent of the time when interacting with a malicious local file. For certain combinations the success rate hit 100 percent. These attacks worked even when individual sub-agents refused to take harmful actions — the orchestrator found workarounds anyway.

The CrewAI and LangGraph situation needs some nuance

Here is where the framing in most posts gets a bit unfair. Palo Alto Networks Unit 42 published research in May 2025 that stated explicitly that CrewAI and AutoGen frameworks are not inherently vulnerable. The risks come from misconfigurations and insecure design patterns in how developers build with them, not from the frameworks themselves.

That said — the default setups leave basically every security decision to the developer with very little enforcement. The shared .env approach for credentials is genuinely how most people start and it is genuinely a problem if you carry it into production. CrewAI does have task-level tool scoping where you can restrict each agent to specific tools, but it is not enforced by default and most tutorials do not cover it.

Also, and this was not in the original material anywhere — Noma Labs found a CVSS 9.2 vulnerability in CrewAI's own platform in September 2025. An exposed internal GitHub token through improper exception handling. CrewAI patched it within five hours of disclosure, which is honestly a good response. But it is worth knowing about.

The honest question

If you are running multi-agent systems in production right now, the thing worth asking yourself is whether your security layer is something you actually built, or whether it is mostly a shared credentials file and some hope. The 2025 incident list is a fairly detailed description of what the failure mode looks like when the answer is the second one.

The security community is catching up — OWASP now explicitly covers multi-agent attack patterns, frameworks are adding scoping mechanisms. The problem is understood. Most production deployments are just running ahead of those protections right now.