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