Claude Code Followed a Symlink at Write Time - CVE-2026-103435 Arbitrary File Write Outside the Project
On October 5, 2026, Anthropic published GHSA-5j29-h97v-84ch, assigned CVE-2026-103435: Claude Code checked that a file it was about to write sat inside the project, then wrote to wherever the path pointed by the time the write happened. Swap the file for a symlink in between and the write lands outside the project. CVSS 4.0 7.7, High, three weaknesses on the record (path traversal, symlink following, and the race that joins them), fixed in Claude Code 2.1.129, reported through HackerOne by c_h4ck_0.
It is a classic bug in a new host. Time-of-check, time-of-use races against the filesystem are as old as multi-user systems, and the fix is as old too: check the resolved path at the moment of use, or open the file in a way that refuses to follow a link. What changes with a coding agent is who is doing the writing. The write Claude Code performs was approved, by a user or by a permission rule, for a path that looked fine. The approval was correct. The destination was not.
What to do now
- Confirm every Claude Code install is on 2.1.129 or later. Auto-updating installs already are. The gap is machines where updates are disabled, pinned, or failing.
- Prioritise shared machines. The precondition is another principal with write access to the same checkout: shared dev servers, long-lived CI runners, multi-user containers, repositories on network mounts.
- Review who can write into checkouts that privileged sessions use. If a build account's Claude Code session edits a repository that a contractor can also write to, that is the configuration the advisory describes.
- Keep the three October floors together: Claude Code 2.1.129 (this), 2.1.179 (CVE-2026-86063), Claude Desktop 1.8089.0 (CVE-2026-88066).
How the bug works
- Claude Code decides to write
project/notes.md. At permission-check time it resolves the path and confirms it is inside the project working directory. The check passes, and any prompt the user sees names that file. - The attacker, who has write access to the workspace, atomically replaces
notes.mdwith a symlink to a file outside the project, for example the shell configuration of the account running the session. - At write time Claude Code resolves the path again, follows the link, and does not repeat the containment check.
- The approved content is written to the target of the link. The attacker chose the destination; the user approved the content.
The CVSS vector (AV:N/AC:L/AT:P/PR:N/UI:P) records the two preconditions as attack requirements and passive user interaction: the user has to be running a session that writes, and the attacker has to be positioned to win the race. The advisory names the realistic victim: a higher-privileged session editing a workspace that a lower-privileged attacker can also write to. No workaround is listed. The fix is in the write path, and 2.1.129 carries it.
The approval was for a path, not a destination
How Claude Code permissions work is a question about paths: a rule allows Edit on files under the project, the prompt shows a file under the project, the user says yes. CVE-2026-103435 shows the limit of that model when the filesystem can change under it. The decision was sound on the information available at decision time, and the information was stale by write time. The same gap was the point of the SymJack findings against several coding agents earlier this year, where the approval dialog could not show the real target of a write, and it is the reason our permissions and hooks hardening guide treats the hook layer and the version floor as two separate controls.
There is also a timing lesson in the record itself. The fix shipped in 2.1.129. The advisory came on October 5, and the two that followed it in the same nine days, the plugin pin bypass on October 9 and the Windows git.exe search-path bug on October 13, both name fixes that are already in the field. For a defender that means the CVE feed is the trailing indicator. The leading one is how quickly your fleet picks up releases that have no name yet, which is a question about auditing Claude Code across a fleet rather than about this bug.
How Anomity surfaces and governs it
See it. The Anomity Endpoint Sensor inventories Claude Code on every managed machine with its version, so the installs still below 2.1.129 are a query, and the inventory shows which of those machines are shared. Metadata only; secrets are redacted on the endpoint.
Enforce before the call runs. On Claude Code, Anomity decides allow, deny or log at the PreToolUse hook, before the write. A policy can refuse writes into sensitive locations, deny edits in sessions that run as privileged accounts, or log every write on a shared host for review. That decision is taken on the path the agent presents, so it is not a fix for the race; it is a second control that holds on the machines where the version floor is not yet met. Keep the record. Decisions and version changes land in a 90-day audit trail and route to SIEM, Slack, email or Jira. Anomity is SOC 2 Type II and complements EDR, DLP, network and GRC tooling; it does not replace them.
If you cannot list the shared machines running Claude Code and their versions, start there. Book a 30-minute demo and we will show you the inventory for your own fleet.
Frequently asked questions
Am I affected by CVE-2026-103435?
If any Claude Code install is older than 2.1.129, yes. Anthropic says standard auto-update has already delivered the fix. Because 2.1.129 is older than the fixes for the other two October advisories, a fleet that updates normally was patched for this one first. The exposure is on machines where auto-update is disabled or failing, and it matters most where more than one principal can write to the same checkout.
What exactly was the bug?
A time-of-check, time-of-use gap. When Claude Code asked whether it was allowed to write a file, it resolved the path and confirmed the file sat inside the project working directory. When it performed the write, it resolved the path again but did not repeat the containment check. Between those two moments an attacker could atomically replace the project file with a symbolic link to a file elsewhere on disk. The write then followed the link and landed outside the project.
Who can exploit it?
Someone who already has write access to the workspace and can time the swap against the agent's write. On a single-user laptop that is usually the user themselves, which is not an attack. On a shared development server, a CI runner with a persistent checkout, a pair-programming container or any repository mounted for more than one account, a lower-privileged user can redirect the edits a higher-privileged Claude Code session makes into that session's own configuration files, for example a shell profile that runs on next login.
Does the permission prompt protect against it?
Not for this bug. The prompt, where one is shown, describes the path the user sees, which is the project file. The check passed on that path. The redirection happens after the decision, at write time, so the approval was given for an edit that then went somewhere else. This is the same shape as the SymJack class of findings against several coding agents earlier this year, where the approval dialog could not show the real write target.
Why was the advisory published after the fix?
Anthropic published the advisory on October 5 for a fix that shipped in 2.1.129, which is well behind the current release line. Coordinated disclosure through HackerOne normally lands the fix first and the public record afterwards. For defenders the consequence is simple: the published advisory is not the first moment you were exposed, and a fleet that updates promptly is protected by fixes that do not have a name yet.
How does Anomity help with this?
The Anomity Endpoint Sensor inventories Claude Code on every managed machine with its version, so the installs still below 2.1.129 are a query rather than a survey, and the same inventory shows which of those machines are shared. On Claude Code, Anomity decides allow, deny or log at the PreToolUse hook before a tool call runs, which lets a policy restrict writes to sensitive paths or deny writes in sessions running as privileged accounts. Decisions land in a 90-day audit trail that routes to SIEM, Slack, email or Jira.
