Claude Code selected an API key stored by Claude Code, for example from an earlier /login or written directly to its configuration, ahead of the user's valid Claude Enterprise or Team sign-in when fetching the organization's server-managed settings, even though the session itself authenticated with the Enterprise or Team account. When the settings endpoint rejected that stored key, the session started without the organization's server-managed policy (such as permission deny rules, model restrictions and managed-only locks) or, if a previously cached copy existed on the machine, kept applying that stale copy without receiving later policy changes — while continuing to operate as the organization's account. Triggering this required local access to a device with such a stored API key; the no-policy case additionally required that no managed settings had previously been cached. Endpoint-managed (MDM or file-based) settings were not affected. Claude for Enterprise organizations were affected from version 2.0.68; Claude for Work (Team) organizations from version 2.1.38, when server-managed settings became available to them.

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

Thank you to Tamas Voros / NVIDIA AI Red Team for reporting this issue.

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!

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.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 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.

Claude Code failed to strictly enforce deny rules configured in settings.json when accessing files through symbolic links. If a user explicitly denied Claude Code access to a file (such as /etc/passwd) and Claude Code had access to a symbolic link pointing to that file, it was possible for Claude Code to read the restricted file through the symlink without triggering deny rule enforcement.

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

Claude Code thanks https://hackerone.com/ofirh for reporting this issue.

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.

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.