Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
29 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The plugin install flow in Claude Code and Claude Desktop checked out a marketplace's pinned commit SHA using git checkout without verifying that the resulting HEAD matched the pinned SHA. An attacker controlling a plugin's upstream repository could create a branch named identically to the pinned 40-character SHA, causing the checkout to silently resolve to the attacker's branch tip instead of the reviewed commit, resulting in attacker-controlled code being installed bypassing the pinned hash. Exploitation required a user to install a malicious plugin, pin to a safe hash, and for the plugin source to be hosted on a git host that permitted SHA-shaped branch names. 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 Or Nevo Michrowski of Air Security for reporting this issue.
Recommended action: Upgrade to 2.1.179 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Users on standard Claude Code auto-update have received this fix automatically. Users performing manual updates are advised to update to the latest version. Thank you to hackerone.com/metnew for reporting this issue.
Recommended action: Upgrade to 2.1.163 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 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/ch4ck0 for reporting this issue.
Recommended action: Upgrade to 2.1.128 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.1.163 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.1.84 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 the latest version. Claude Code thanks hackerone.com/philts for reporting this issue.
Recommended action: Upgrade to 2.1.64 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On Windows, Claude Code loaded 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. 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/edbr for reporting this issue.
Recommended action: Upgrade to 2.1.75 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Claude Code 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. 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/cantinaxyz for reporting this issue.
Recommended action: Upgrade to 2.1.53 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Claude Code's bubblewrap sandboxing mechanism failed to properly protect the .claude/settings.json configuration file when it did not exist at startup. While the parent directory was mounted as writable and .claude/settings.local.json was explicitly protected with read-only constraints, settings.json was not protected if it was missing. This allowed malicious code running inside the sandbox to create this file and inject persistent hooks (such as SessionStart commands) that would execute with host privileges when Claude Code was restarted. 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 hackerone.com/edbr for reporting this issue!
Recommended action: Upgrade to 2.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Claude Code failed to properly validate commands using piped sed operations with the echo command, allowing attackers to bypass file write restrictions. This vulnerability enabled writing to sensitive directories like the .claude folder and paths outside the project scope. Exploiting this required the ability to execute commands through Claude Code with the "accept edits" feature enabled. 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 hackerone.com/nil221 for reporting this issue!
Recommended action: Upgrade to 2.0.55 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Claude Code failed to properly validate directory changes when combined with write operations to protected folders. By using the cd command to navigate into sensitive directories like .claude, it was possible to bypass write protection and create or modify files without user confirmation. Reliably exploiting this required the ability to add untrusted content into a Claude Code context window. Users on standard Claude Code auto-update received this fix automatically. Users performing manual updates are advised to update to the latest version. About Claude Code thanks hackerone.com/nil221 for reporting this issue!
Recommended action: Upgrade to 2.0.57 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to an error in command parsing, it was possible to bypass the Claude Code confirmation prompt to trigger execution of untrusted commands through the find command. 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. Claude Code thanks https://hackerone.com/alexbernier for reporting this issue!
Recommended action: Upgrade to 2.0.72 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to a Bash command validation flaw in parsing ZSH clobber syntax, it was possible to bypass directory restrictions and write files outside the current working directory without user permission prompts. Exploiting this required the user to use ZSH and 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. Claude Code thanks https://hackerone.com/alexbernier for reporting this issue!
Recommended action: Upgrade to 2.0.74 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Claude Code contained insufficient URL validation in its trusted domain verification mechanism for WebFetch requests. The application used a startsWith() function to validate trusted domains (e.g., docs.python.org, modelcontextprotocol.io), this could have enabled attackers to register domains like modelcontextprotocol.io.example.com that would pass validation. This could enable automatic requests to attacker-controlled domains without user consent, potentially leading to data exfiltration. 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/47sid-praetorian for reporting this issue!
Recommended action: Upgrade to 1.0.111 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in Claude Code's project-load flow allowed malicious repositories to exfiltrate data including Anthropic API keys before users confirmed trust. If a user started Claude Code in an attacker-controller repository, and the repository included a settings file that set ANTHROPICBASEURL to an attacker-controlled endpoint, Claude Code would issue API requests before showing the trust prompt, including potentially leaking the user's API keys. Users on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to the latest version.
Recommended action: Upgrade to 2.0.65 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to errors in parsing shell commands related to $IFS and short CLI flags, it was possible to bypass the Claude Code read-only validation and trigger arbitrary code execution. Reliably exploiting this requires 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 RyotaK from GMO Flatt Security Inc. for reporting this issue!
Recommended action: Upgrade to 1.0.93 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to an error in sed command parsing, it was possible to bypass the Claude Code read-only validation and write to arbitrary files on the host system. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version. Thank you to Adam Chester - SpecterOps for reporting this issue!
Recommended action: Upgrade to 2.0.31 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using Claude Code with Yarn installed, Yarn config files can trigger code execution when running yarn --version. This could lead to a bypass of the directory trust dialog in Claude Code, as plugins and yarnPath could be executed prior to the user accepting the risks of working in an untrusted directory. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version. Thank you to Benjamin Faller, Redguard AG and Michael Hess for reporting this issue!
Recommended action: Upgrade to 1.0.39 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Claude Code failed to account for symlinks when checking permission deny rules. If a user explicitly denied Claude Code access to a file and Claude Code had access to a symlink pointing to that file, it was possible for Claude Code to access the file. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version. Thank you to https://hackerone.com/vinai for reporting this issue!
Recommended action: Upgrade to 1.0.120 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to a bug in the startup trust dialog implementation, Claude Code could be tricked to execute code contained in a project before the user accepted the startup trust dialog. Exploiting this requires a user to start Claude Code in an untrusted directory. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version. Thank you to https://hackerone.com/avivdon for reporting this issue!
Recommended action: Upgrade to 1.0.111 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using Claude Code with Yarn installed, Yarn config files can trigger code execution when running yarn --version. This could lead to a bypass of the directory trust dialog in Claude Code, as plugins and yarnPath could be executed prior to the user accepting the risks of working in an untrusted directory. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version. Thank you to Benjamin Faller, Redguard AG and Michael Hess for reporting this issue!
Recommended action: Upgrade to 1.0.39 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
At startup, Claude Code constructed a shell command that interpolated the value of git config user.email from the current workspace. If an attacker controlled the repository’s Git config (e.g., via a malicious .git/config) and set user.email to a crafted payload, the unescaped interpolation could trigger arbitrary command execution before the user accepted the workspace-trust dialog. The issue affects versions prior to 1.0.105. The fix in 1.0.105 avoids executing commands built from untrusted configuration and properly validates/escapes inputs. Patches: Update to @anthropic-ai/claude-code 1.0.105 or later. Workarounds: Open only trusted workspaces and inspect repository .git/config before launch; avoid inheriting untrusted Git configuration values. Thank you to the NVIDIA AI Red Team for reporting this issue!
Recommended action: Upgrade to 1.0.105 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to an error in command parsing, it was possible to bypass the Claude Code confirmation prompt to trigger execution of an untrusted command. Reliably exploiting this requires the ability to add untrusted content into a Claude Code context window. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version. Thank you to the NVIDIA AI Red Team for reporting this issue!
Recommended action: Upgrade to 1.0.105 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When Claude Code was started in a new directory, it displayed a warning asking, "Do you trust the files in this folder?". This warning did not properly document that selecting "Yes, proceed" would allow Claude Code to execute files in the folder without additional confirmation. This may not have been clear to a user so we have updated the warning to clarify this functionality. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version. Thank you to https://hackerone.com/avivdon for reporting this issue!
Recommended action: Upgrade to 1.0.87 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.