Anthropic published two security advisories for Claude Code within a week. GHSA-gfvf-j8jh-jxxw (CVE-2026-103012), published on 29 September 2026, covers sessions that could start without an organization's server-managed policy. GHSA-5j29-h97v-84ch (CVE-2026-103435), published on 5 October, covers a time-of-check to time-of-use race that let an attacker redirect Claude Code's file writes outside the project directory. Both are fixed, and auto-updating installs already have the fixes.
What's affected
Both advisories cover the npm package @anthropic-ai/claude-code.
- CVE-2026-103435, symlink write race: affects versions before 2.1.129, fixed in 2.1.129. Rated High, CVSS v4 7.7.
- CVE-2026-103012, managed settings skipped: affects 2.0.68 and later versions before 2.1.260, fixed in 2.1.260. Rated Low, CVSS v4 2.0.
CVE-2026-103435. Claude Code checked that a target path sat inside the project working directory when it asked for permission, then resolved the path again at write time without repeating the check. Someone who can write to the same workspace could swap a project file for a symlink in that gap, and Claude Code would follow it and write somewhere else. The advisory's example is a lower-privileged user redirecting a benign edit into a higher-privileged user's shell configuration. It requires winning a race and having write access to the shared workspace. The reporter is credited as hackerone.com/c_h4ck_0.
CVE-2026-103012. When fetching an organization's server-managed settings, Claude Code preferred an API key it had stored, for example from an earlier /login, over the user's valid Claude Enterprise or Team sign-in. If the settings endpoint rejected that key, the session started with no server-managed policy, meaning no permission deny rules, model restrictions or managed-only locks. If an older policy was cached on the machine, Claude Code kept applying that stale copy instead. Meanwhile the session still ran as the organization's account.
Enterprise organizations were affected from 2.0.68 and Team organizations from 2.1.38, when server-managed settings became available to them. Endpoint-managed settings delivered by MDM or a file were not affected. Tamas Voros of the NVIDIA AI Red Team reported it.
How to check if you're exposed
Check the installed version on each machine:
claude --version
npm ls -g @anthropic-ai/claude-code 2>/dev/null
Anything below 2.1.260 is missing the managed settings fix, and anything below 2.1.129 is missing both.
For CVE-2026-103012, run /status inside Claude Code and read the Setting sources line. Claude Code's documentation says the managed settings entry shows in parentheses how the policy reached the machine. If your organization relies on server-managed settings and that entry is missing, the session is not enforcing your policy.
For CVE-2026-103435, the exposure is narrower. Ask where Claude Code runs in a directory that other users or processes can write to: shared build hosts, multi-user dev boxes, mounted volumes in containers.
# World- or group-writable directories under a shared workspace root
find /srv/workspaces -type d \( -perm -0002 -o -perm -0020 \) 2>/dev/null | head
What to do now
-
Update. Users on standard auto-update already have both fixes. For manual installs:
npm install -g @anthropic-ai/claude-code@latest claude --versionConfirm the result is 2.1.260 or later.
-
Pin a floor in your fleet tooling. If you package Claude Code in images or golden machines, set the minimum version to 2.1.260 so older copies don't creep back in.
-
Verify policy is applied. On a sample of developer machines, check
/statusand confirm the managed source is listed. Do it again after the update. -
Consider a device-delivered policy for critical rules. The advisory states that MDM and file-based managed settings were not affected. Organizations that need deny rules to hold even when a network fetch fails can deliver the same rules through the endpoint channel.
-
Don't share writable workspaces across trust levels. Give each user their own checkout on shared hosts, and avoid running an agent as a privileged user in a directory a less privileged user can write to.
Why it matters
CVE-2026-103435 is a classic file-handling bug in a new place. Agents make many small writes on a user's behalf, and every one of them is a path decision. A check at approval time and a separate resolution at write time leaves a window, and symlinks are the oldest way to use it.
CVE-2026-103012 is about governance rather than code execution. Its score is low because it needs local access and a stored key. The lesson is broader: an organization's guardrails for an AI agent are only as reliable as the path that delivers them. When that path fails quietly, the agent keeps working with fewer rules and nobody is told.
Both are good reasons to check what policy is actually in force on a machine, not just what the admin console says.
Try it yourself
Pick one team and build a quick inventory of which Claude Code versions are installed on their machines and in CI images. Count how many are below 2.1.260. Then see how a dependency inventory makes that kind of question a single search.
Click through it at your own pace, or open it full screen.
Quick check
Does CVE-2026-103012 let an attacker run code?
No. It causes a session to run without the organization's server-managed policy, or with a stale cached copy. Triggering it requires local access to a device that has a stored API key.
Is a single-user laptop exposed to CVE-2026-103435?
Much less so. The attack needs someone else with write access to the same workspace and the ability to win a race against Claude Code's write. Shared hosts and shared volumes are the realistic targets.
Which version fixes both issues?
2.1.260 or later. The symlink fix arrived in 2.1.129 and the managed settings fix in 2.1.260.
