Three Claude advisories in October, for fixes that shipped months earlier

Between 5 and 13 October 2026, Anthropic published three security advisories for Claude Code and Claude Desktop, each rated high. All three describe ways a repository, plugin or shared workspace someone else controls could make the tool write or run something it shouldn't. For two of them, the fixed Claude Code version was released in May or June, months before the advisory. The advisories say machines on standard auto-update already have the fixes. Machines that don't auto-update are the ones to find, and the gap between a fix and its advisory is a good reason to check how your team's AI tools get updated.

The three advisories

A file write that followed a symlink

GHSA-5j29-h97v-84ch, published 5 October, describes a time-of-check to time-of-use gap. Claude Code checked that a file it was about to edit sat inside the project, but resolved the path again when writing without repeating the check. Someone who could write to the same workspace could swap a project file for a symlink at the right moment, and Claude Code would write its output wherever the link pointed, such as a shell configuration file. The advisory notes that exploitation needed write access to the shared workspace and winning a race. It is rated high, with a CVSS 4.0 score of 7.7, and fixed in Claude Code 2.1.129, which was released on 6 May.

A plugin pin that didn't pin

GHSA-pq7j-f95f-qfcv, published 9 October, concerns plugins pinned to a commit. The install flow in Claude Code and Claude Desktop checked out the pinned commit hash without verifying that the result matched it. Whoever controlled the plugin's upstream repository could create a branch whose name was the same 40-character hash, and the checkout would quietly land on that branch instead of the reviewed commit. Exploitation needed a user to install the plugin and pin it, and a git host that allows branch names shaped like hashes. It is rated high, CVSS 4.0 7.7, and fixed in Claude Code 2.1.179, released on 16 June.

A git executable found in the project folder

GHSA-4p2j-qj3c-6x84, published 13 October, affects Claude Desktop on Windows. It started git.exe without an absolute path, so Windows searched the current folder before the system folders. A git.exe planted in a project, for example in a cloned repository, ran as soon as the user opened that folder in Claude Desktop. The advisory calls it remote code execution through supply-chain routes such as cloned repositories. It is rated high, CVSS 4.0 7.5, and fixed in Claude Desktop 1.8089.0. The advisory doesn't say when that version was released.

All three advisories carry the same note: users on standard auto-update have already received the fix, and those who update manually should move to the latest version.

What the pattern shows

None of the three involves the model. Each is a mistake in the harness around it: path handling, a git checkout, a process search path. They share one assumption that turned out to be wrong, that a project folder or plugin source is passive data. To a coding agent, a repository is input that its tooling acts on: it reads configuration from it, calls git inside it and writes into it. The bugs sit exactly where the tool trusted what it found there.

The pinned plugin case deserves particular attention, because pinning is the control security teams recommend for third-party code. A pin is only as good as the check that the pinned thing is what was installed. Here the pin was recorded but not verified, so a careful team that pinned every plugin was no better protected than one that didn't, against an attacker who controlled the upstream repository.

The timing matters as much as the content. Release notes for a fix often say little; the advisory with the impact and the CVSS score can come months later. A team that decides when to update by reading advisories was, in this case, months late. A team whose developers install through channels that don't update on their own was exposed for the whole of that time without knowing it.

How Claude Code updates, and where it doesn't

The Claude Code setup documentation is clear about which installs keep themselves current. Native installations update in the background and apply the update on the next start. Homebrew, WinGet and Linux package manager installations do not auto-update by default; they need an explicit upgrade. Auto-updates can also be switched off with DISABLE_AUTOUPDATER, and all updates blocked with DISABLE_UPDATES, which some companies use to distribute versions through their own tooling.

For organisations, the same page describes two managed settings worth knowing: minimumVersion sets a floor below which updates won't install, and requiredMinimumVersion and requiredMaximumVersion make Claude Code refuse to start outside a version range. claude doctor reports the result of the last update attempt.

What it means for engineering and security leaders

• Your exposure depends on install channel, not on policy. Two developers on the same team can be months apart because one installed with a package manager.
• Advisories are a lagging signal. Use them to confirm you are covered, not to decide when to update.
• Plugins and repositories are code. Opening an untrusted repository in an AI coding tool is closer to running a build script than to reading a document.

Practical takeaways

• Find every Claude Code install below 2.1.179 and every Windows Claude Desktop install below 1.8089.0, and update them.
• Check how each machine installs Claude Code. Homebrew, WinGet, apt, dnf and apk installs need an upgrade step in your normal patching.
• If you manage settings centrally, set requiredMinimumVersion to a current version, so that a machine left behind refuses to start rather than running an old build.
• Review where DISABLE_AUTOUPDATER or DISABLE_UPDATES is set, and make sure whoever owns that distribution has a schedule.
• Open repositories you don't trust only in a disposable environment, and treat plugin pins as something to verify, not just record.

Finding the machines is often the hard part. SpanDock's process inventory, on the Enterprise plan and in the 30-day trial, is off by default; when it is on, it shows which AI tools run on your team's computers, including ones that send no telemetry. A snapshot holds each program's name and path rather than its version, so it tells you where Claude Code and Claude Desktop run; the version check is still done with the tool itself.