On this page
If you use Claude Code on a Mac with its sandbox turned on, a booby-trapped project could get Claude Code to overwrite files outside that project: your shell settings, your notes, anything your user account can write. The sandbox is supposed to keep a project's scripts inside the project folder. This bug let a script hand Claude Code's own file editor a different target after the safety check had already passed. It is tracked as CVE-2026-88968 and fixed in Claude Code 2.1.251.
The fix is old news for most people. Version 2.1.251 reached npm on Aug 28, 2026, and Anthropic says anyone on standard auto-update already has it. The advisory only went public in late October, and GitHub's reviewed entry landed on Nov 9, which is when dependency scanners started flagging it. So the people with work to do are the ones whose Claude Code does not update itself.
How to fix
Update Claude Code to 2.1.251 or later, then quit and restart any open sessions. Updates take effect the next time Claude Code starts.
claude update
That works for the native installer. For the other install methods:
# npm global install
npm install -g @anthropic-ai/claude-code@latest
# Homebrew (use the cask name you installed)
brew upgrade claude-code
brew upgrade claude-code@latest
Anthropic's setup docs warn against npm update -g here, because it respects the version range from your original install and may not move you to the newest release. As of Nov 10 the latest release is 2.1.322 and the stable channel is on 2.1.311, so either channel puts you well past the fix.
Check your Mac in two commands
claude --version
claude doctor
The first must print 2.1.251 or higher. In the second, look at the Auto-updates line. If it says enabled and the last update attempt succeeded, you are covered and will stay covered. If it says disabled (set by env: DISABLE_AUTOUPDATER), someone turned background updates off in settings.json, and you need to update by hand from now on.
Your install method decides whether you have anything to do. According to Anthropic's setup docs, Homebrew installs do not auto-update by default, and neither do WinGet, apt, dnf or apk installs. An npm global install also stops updating if npm's global folder is not writable; Claude Code shows a one-time notice about that at startup and lists fixes in claude doctor. If you installed with Homebrew in the summer and never ran brew upgrade, you are the person this advisory is for.
Who is not affected
- Anyone who never turned the sandbox on. Claude Code's Bash sandbox is off by default. You enable it with
/sandboxorsandbox.enabledin settings. The advisory is about a process inside the sandbox reaching outside it. Without the sandbox there is no fence to get around: commands Claude runs already have your account's full access, and the thing standing between a bad script and your files is the permission prompt, not this bug. - Linux, WSL2 and Windows users. The advisory and the NVD record both say the attack works on macOS. On Linux and WSL2 the sandbox is built on bubblewrap rather than macOS Seatbelt, and on native Windows Claude Code does not sandbox commands at all.
- Auto-update users on 2.1.251 or later. Per the advisory, they received the fix automatically.
- Anyone who only opens code they trust. The attacker's code has to already be running inside the sandbox, for example from a malicious repository or a dependency's install or build script.
What this is not
This is not something a stranger can do to you over the internet, and it does not run code on your Mac by itself. It is a file overwrite: an attacker who already has a script running in your sandboxed session can make Claude Code write over one file you have permission to change. That can still turn into more. Overwrite a shell startup file such as ~/.zshrc and whatever the attacker writes there runs the next time you open a terminal, outside any sandbox. That is why the advisory rates it high (CVSS 4.0 score 7.7) and not low.
What went wrong
The bug is a classic check-then-use race, filed as CWE-367 and CWE-59. When Claude asks to edit a file, Claude Code checks that the path sits inside the workspace, resolving any symlinks at that moment. The advisory says that check was "not bound to the underlying directory inodes or file descriptors." In plain terms, it checked a name, not the actual folder behind the name.
The edit itself does not run inside the sandbox. So a script that is inside the sandbox, and that cannot write outside the project on its own, waits for the check to pass and then swaps a folder in the project for a symlink pointing somewhere else in your home directory. The edit follows the new path and writes there. The sandbox stopped the script from writing outside the project; it did not stop the script from steering a tool that was never sandboxed.
The 2.1.251 release notes describe the fix more broadly than the advisory: "Fixed file tools (Read, Write, Edit) following a symlink swapped inside the working directory after the permission check, which could read or write outside the approved location." The CVE covers the Edit write on macOS. The same release also closed the matching gap for Read and Write, plus a separate fix for Grep and Glob not applying Read(...) deny rules through symlinked search paths. If you rely on file permission rules in Claude Code, that whole release is worth having.
If you turned the sandbox on, test it
A sandbox you have never tested is a guess. Anthropic's sandbox docs give a quick probe: ask Claude to run touch ~/sandbox-probe. On macOS it should fail with Operation not permitted. If Claude offers to retry outside the sandbox, say no. If the file gets created and your home folder is not on your allowed-write list, delete it and run /sandbox to see what is off.
The docs also describe a strict mode, "allowUnsandboxedCommands": false, which stops Claude Code from offering that unsandboxed retry at all. Teams that turned on the sandbox specifically to open unfamiliar repos should consider it.
The other lesson is about what the sandbox covers. Anthropic's docs say the built-in file tools (Read, Edit, Write) follow permission rules, not the sandbox's filesystem rules. This CVE lived in the gap between those two systems. If you want one more checkpoint in front of what an agent does to your files and shell, that is the job HOL Guard was built for: it reviews an agent's commands and file access before they run and asks you when something looks wrong.
Timeline
- Aug 28, 2026: Claude Code 2.1.251 published to npm with the fix.
- Oct 26, 2026: advisory GHSA-5xjx-9qx6-jcrv published on the anthropics/claude-code repository.
- Nov 3, 2026: CVE-2026-88968 published to NVD (awaiting NVD analysis at the time of writing).
- Nov 9, 2026: GitHub reviewed advisory published, which feeds Dependabot and other scanners.
Not on CISA's exploited list, and the advisory does not report exploitation. Credit to Sunder Singh (hackerone.com/mahoraga007) for the report. This is a different issue from the tampered Claude Code builds in Cursor's marketplace we covered on Oct 30.
What do people ask about CVE-2026-88968?
Which Claude Code versions are affected by CVE-2026-88968?
All versions of @anthropic-ai/claude-code before 2.1.251. Version 2.1.251 and later are fixed.
Do I need to do anything if Claude Code auto-updates?
Usually no. Run claude --version to confirm you are on 2.1.251 or later, and check that claude doctor shows auto-updates as enabled. Homebrew, WinGet and Linux package manager installs do not auto-update by default.
Does CVE-2026-88968 affect Claude Code on Linux or Windows?
The advisory describes the attack on macOS only. On Linux and WSL2 the sandbox uses a different mechanism, and native Windows does not sandbox commands.
Can someone attack me remotely with this bug?
No. The attacker needs code already running inside Claude Code's sandbox on your Mac, typically from a malicious repository or dependency script you opened or ran.
What can an attacker actually do with it?
Overwrite a file outside your project that your user account can write to. Overwriting a shell startup file is one way that becomes code running outside the sandbox later.
