Symlinks Are Still Scary (And Yes, You Can Commit Them to Git)

What it is

A Snyk blog post (Randall Degges, July 9 2026) on symlink attacks delivered through Git repositories. Beyond the AI-assistant incident the summary describes, the page supplies the concrete Git internals, the platform boundary, and the detection tells an engineer needs to reason about their own exposure.

How it works

A symlink is a file whose entire contents are a path; the OS transparently redirects any open of the link to that target. Git stores symlinks with file mode 120000, and the blob content is nothing but the target path as plain text. So a file named e.g. project_settings.json can have blob contents of /home/rdegges/.ssh/authorized_keys. On clone, Git faithfully recreates the symlink on disk. Nothing has been exploited yet — the danger is the next tool (build script, editor, AI agent) that reads or writes through the checkout without resolving where the path actually goes, turning a clone into arbitrary file read/write and often RCE. The archive-tool variant (tar/zip/npm) extracts a symlink and writes through it to escape the target directory — CVE-2021-32803 in the tar npm package is the textbook case.

Preconditions / Affected

• Linux and macOS primarily. On Windows, Git leaves symlinks as plain text files unless core.symlinks is enabled — so this "mostly bites Linux and macOS, which is to say most developer laptops and nearly all CI."
• A tool that opens paths in a checkout without resolving them. Git's own checkout is not the weak point (see Caveats).

What to do

Inspect suspicious files before any tool touches them. ls -l reveals a symlink by the leading l and the -> in the listing; readlink <file> prints the target path the link points at rather than following it. GitHub renders symlinks correctly in its UI, so they are spottable in the web view if you know to look.

Caveats

• Git was already partly hardened by the 2021-era CVEs: modern Git will not follow a symlink to write outside the working tree or into .git during its own operations. That protects only the checkout step — Git still legitimately creates the symlink as an inert file, and cannot control what reads it afterward.
• Detection relies on someone actually looking; "nobody's auditing every file in every dependency they pull," which is the gap the attack exploits.
• The fetched text is truncated mid-sentence in the mitigation discussion, so the post's full remediation guidance is not captured here.

flowchart TD
    A[Clone repo with malicious symlink] --> B{Tool resolves path<br/>before open?}
    B -->|Yes / ls -l, readlink| C[Symlink spotted — safe]
    B -->|No: build, editor, AI agent| D[Writes/reads through link]
    D --> E[File access outside repo → RCE]