Claude Code before 2.1.179 could install attacker-controlled plugin code even when the plugin was pinned to a specific commit hash. The flaw is tracked as CVE-2026-86063 (GHSA-pq7j-f95f-qfcv), rated high (CVSS v4 7.5). Run claude --version; if it is below 2.1.179, update.
| Question | Short answer |
|---|---|
| Am I affected? | If you run Claude Code older than 2.1.179 and install plugins from marketplaces |
| Is there a fix? | Yes: 2.1.179. Standard auto-update users already have it |
| What does it break? | Hash pinning, the control that was supposed to guarantee you get the reviewed commit |
| Exploited in the wild? | The advisory does not say so |
| Does data leave my machine? | Not by the flaw itself; the installed plugin code could do anything a plugin can |
How the hash pin bypass works
Plugin marketplaces list where each plugin comes from. A source can be pinned to a commit with sha (or a ref), as described in the Claude Code marketplace docs. The point of a pin is that a reviewed commit stays the commit you get, even if the upstream repo changes later.
Per the advisory, the installer ran a checkout of the pinned SHA but never confirmed the resulting HEAD matched it. That opens a git quirk:
- An attacker controls the plugin's upstream repository.
- They create a branch whose name is exactly the pinned commit SHA.
- When the installer checks out that string, git can resolve it to the attacker's branch rather than the commit.
- Attacker-controlled code is installed, and the pin gave a false sense of safety.
The advisory notes the host must allow SHA-formatted branch names, and the user must install a plugin pinned to a hash they believed was safe. It maps the issue to CWE-494 (download of code without integrity check) and CWE-829. It credits Or Nevo Michrowski of Air Security with the report.
The advisory text is specific about three preconditions. The user has to install a malicious plugin. The marketplace entry has to pin that plugin to a safe hash. And the plugin source has to sit on a git host that permits SHA-shaped branch names. All three must hold, which narrows the practical risk, but the first two describe an ordinary workflow. A pin is exactly what a careful marketplace owner adds after reviewing a commit, so the people who used the control correctly were the ones exposed.
The advisory also says the install flow in "Claude Code and Claude Desktop" was affected, not only the terminal client. If you install plugins through the desktop app, check that app's version as well as the CLI.
Why a branch name can beat a commit hash
A 40-character SHA is a name for one immutable commit. A branch is a movable pointer, and git lets anyone with write access name a branch almost anything. When a tool passes a bare string to git checkout, git has to decide whether the string means a commit or a ref. The git documentation for revision names lists the full object name and the various refs/ lookups as separate forms, and it describes a disambiguation order for refnames. The advisory's conclusion is that, in this install flow, the checkout "silently resolve[d] to the attacker's branch tip instead of the reviewed commit."
The missing step is small. After the checkout, the installer needed to ask git for the resulting HEAD commit and compare it with the pinned value. Without that comparison, any string that git accepts as a checkout target is treated as proof that the pin was honoured. The weakness class matches: CWE-494 is "Download of Code Without Integrity Check",.
What the attacker gets
The attacker does not need a vulnerability in the model or in a tool permission. They get the same thing any plugin author gets: files that Claude Code loads. The plugin reference describes what a plugin can contain, including skills, hooks, and MCP and LSP server configuration. The discover-plugins page warns that "a plugin can run hooks and MCP servers, so read the pane before you install." A plugin installed from the wrong commit therefore has the plugin author's full reach: hooks that run on agent events, MCP servers that start as local processes, and skill text that steers the model.
That is why a hash pin matters more than it first appears. Reviewing a plugin is a one-time act, and the pin is what carries the result of that review forward to every later install.
Timeline and disclosure
- October 9, 2026: the advisory was published to the
anthropics/claude-coderepository, per the GitHub record. - October 13, 2026: the CVE record was published by the National Vulnerability Database.
- October 15, 2026: GitHub reviewed the advisory and added it to the GitHub Advisory Database. This is the date that matches this post's first publication.
The v2.1.179 release page lists its changes as stream handling, terminal scrolling, sandbox glob fixes and plugin loading performance. It does not name this fix. That is a reminder to rely on the advisory, not on release notes, when you want to know whether a given version closes a security issue. The advisory states the patched version directly: 2.1.179.
The advisory credits Or Nevo Michrowski of Air Security with the report. It describes no exploitation in the wild and publishes no indicators of compromise.
The anthropics/claude-code advisory list shows this was one of several Claude Code advisories in a short window. It lists a high-severity file-write advisory titled "Arbitrary File Write via Write-Time Symlink Following (TOCTOU) in Claude Code" (October 5) and a high-severity advisory titled "Uncontrolled Search Path Enables Arbitrary Code Execution via Malicious Git Executable" (October 13). Those are separate issues and this post does not cover their details, but if you are updating for the pin fix, read each advisory's patched version rather than assuming one update covers them all.
What this means if you run AI coding agents
- Update.
claude --versionshould report 2.1.179 or later. Auto-update users already received it; if you update manually, move to the latest release. - Re-review pinned plugins you did not write. A pin in a marketplace entry is only as good as the install that honours it. For plugins installed before updating, compare what is on disk with the commit you reviewed.
- Prefer sources you control. For plugins that matter, fork the repo or host it in an organization where you decide who can create branches. A SHA-named branch needs a writer on the upstream.
- Remember what plugins can contain. Plugins ship skills, hooks and MCP configuration, which is why skill and MCP review belongs before install, not after. See also MCP server security review.
- Look at runtime behaviour. After installing anything new, check which commands run and which files are read. The advisory gives no indicators of compromise, so behaviour is your signal.
A short audit routine
If you maintain or use pinned plugins, this order works without any tool beyond git and the Claude Code panel:
- Version first. Run
claude --versionand, for the desktop app, check the version of that app too. Anything below 2.1.179 is in scope for this flaw. - List what you installed from pinned sources. Open
/pluginand use the Installed tab, which the plugin documentation describes as listing your plugins with actions to enable, disable, update or uninstall each one. - Compare commits. For each pinned plugin, find the SHA in the marketplace entry and compare it with the commit of the checkout on disk (
git rev-parse HEADinside the plugin directory). The advisory does not say where installed plugin files live on each platform, so look up the path in the plugin docs for your setup rather than guessing it. - Treat a mismatch as untrusted. Uninstall the plugin, review the upstream repository for a branch named like the pinned SHA, and reinstall only after the update.
- Read the plugin's hooks and MCP entries. These are the parts that execute. A skill is text, but a hook is a command.
The discover-plugins page also notes that plugins from a local or custom marketplace can show "Components will be discovered at installation" in the details pane, which means the pane cannot always show you the hooks and servers before the install. For those plugins the commit comparison matters more.
For marketplace owners
If you publish a marketplace, the marketplace documentation says git-based sources can be pinned to a ref or sha. After this advisory, a pin in your file protects your users only on versions at or above 2.1.179. Say so in your README, and consider asking users to update before they add your marketplace. Also keep write access to the upstream plugin repositories tight: the attack needs someone who can create a branch there.
What Beam can and cannot do here
Beam does not verify git provenance, and this flaw lives in the installer, before any agent tool call. So Beam would not have stopped the bad checkout. Where it helps is afterwards: Beam's PreToolUse hooks for Claude Code can flag or deny risky actions such as credential reads or destructive commands that a rogue plugin steers the agent into, and its skill and MCP scan runs heuristic checks (11 patterns plus an MCP version-pin check) on what you point it at. That is heuristic, not a kernel sandbox. See how Beam works and what to watch.
Why pinning is not the end of the story
This is the same class of problem as the npm worms aimed at AI tooling: a trusted reference quietly resolves to something else. A pin only protects you when the tool verifies what it fetched.
Two other recent Beam posts show the same pattern of a trusted pointer resolving to something else. The MCP TypeScript SDK OAuth credential leak (CVE-2026-104850) covers an MCP client SDK sending OAuth secrets to an authorization server chosen by a malicious MCP server. The Cursor MCP config poisoning RCE covers two 2025 Cursor flaws in which the tool's trust in its own MCP config file turned a prompt injection into code execution. In each case a trust decision rested on a value the tool did not verify.
The wider lesson for anyone who runs coding agents is to separate two questions. "Did I review this code?" is a human question. "Is the code that runs the code I reviewed?" is a verification question, and the tool has to answer it. When a vendor's control depends on the second question, ask how it is checked, and whether you can check it yourself with a one-line command like git rev-parse HEAD.
Frequently asked questions
What is CVE-2026-86063?
It is a high-severity (CVSS v4 7.5) flaw in the plugin install flow of Claude Code. The installer checked out a pinned commit SHA but did not verify that the resulting HEAD matched it, so a branch with the same name as the SHA could be installed instead.
Which versions are affected and which fix it?
Versions before 2.1.179 are affected, and 2.1.179 is the patched release, per the GitHub advisory. Users on standard auto-update already received the fix.
What does an attacker need to exploit it?
Control of the plugin's upstream repository on a git service that allows branch names in SHA format, plus a user who installs the plugin believing the hash pin protects them. The advisory does not describe exploitation in the wild.
How do I check my version?
Run claude --version and confirm it reports 2.1.179 or later. If you update manually, upgrade to the latest release.
Are existing plugins I already installed affected?
The advisory covers the install-time checkout, so a plugin installed before the fix from a pinned source you do not control is worth re-reviewing. The advisory does not publish a way to detect past exploitation.
Would Beam have blocked this?
Not reliably. The malicious code arrives through the plugin install, not an agent tool call, and Beam does not verify git provenance. Beam can still flag risky actions the installed plugin later takes through hooks.
Related reading
- Stop Claude Code from running dangerous commands
- Agent skills specification and security review
- MCP server security review
- SneakPeek: Claude Code Desktop preview exfiltration
- GitHub advisory GHSA-pq7j-f95f-qfcv
Details are accurate as of October 15, 2026, based on the GitHub advisory. Check the advisory for later changes.