CVE-2026-71556: Symbolic Link Directory Traversal in go-git

An arbitrary file write vulnerability exists in the worktree implementation of go-git, a widely integrated pure Go implementation of the Git specification. The flaw arises during repository checkout operations when processing paths containing symbolic links that resolve outside the designated worktree directory.\n\nSecurity tools, integrated development environments (IDEs), and continuous integration (CI/CD) pipelines frequently rely on go-git to programmatically clone, fetch, and analyze untrusted remote repositories. This specific vulnerability exposes these automated systems and client environments to high-severity integrity risks.\n\nThe vulnerability, cataloged as CVE-2026-71556 and GHSA-hc8v-wwc9-vgxm, represents a failure to ensure that physical paths map strictly to the intended virtual boundary. An attacker who successfully influences a repository configuration can leverage this discrepancy to execute arbitrary file operations on the host system.

The root cause of this vulnerability lies in the divergence between lexical path validation and physical path resolution. The worktreeFilesystem component in go-git previously restricted operations to the worktree using a string-based validation function named validPath. This function analyzed path strings to detect parent directory segments, metadata directories, and alternative filesystem stream markers.\n\nWhile lexical path checking successfully identifies direct attempts to traverse boundaries, it does not account for the state of the physical filesystem. If a repository contains a symbolic link that points to a path outside the worktree, the operating system's file creation APIs resolve the link dynamically during write operations.\n\nWhen the checkout process creates a symbolic link followed by a file situated logically beneath that link, the lexical check evaluates the second file's path string as benign. The underlying filesystem driver subsequently resolves the previously created symbolic link, which permits the file write operation to escape the root boundary of the worktree.

The vulnerability is resolved by introducing active path state validation and proactive cleanup of blocking symlinks prior to file creation. The implementation introduces clearBlockingSymlinks, which recursively verifies the target path from the shallowest directory component downward.\n\ngo\nfunc (w *Worktree) clearBlockingSymlinks(name string) error {\n\tvar dirs []string\n\tfor dir := filepath.Dir(name); dir != \".\" && dir != \"\" && dir != string(filepath.Separator); dir = filepath.Dir(dir) {\n\t\tdirs = append(dirs, dir)\n\t}\n\tfor i := len(dirs) - 1; i >= 0; i-- {\n\t\tfi, err := w.Filesystem.Lstat(dirs[i])\n\t\tif err != nil {\n\t\t\tif os.IsNotExist(err) {\n\t\t\t\tcontinue\n\t\t\t}\n\t\t\treturn err\n\t\t}\n\t\tif fi.Mode()&os.ModeSymlink != 0 {\n\t\t\treturn w.Filesystem.Remove(dirs[i])\n\t\t}\n\t}\n\tfi, err := w.Filesystem.Lstat(name)\n\t// ... remaining check for final component symlink\n}\n\n\nAdditionally, the worktreeFilesystem wrapper was hardened to perform on-disk validation via validNoLeadingSymlink for every read and write operation. This ensures that any path containing a leading component that physically exists on disk as a symbolic link is rejected before passing the path to the physical driver.

To execute this attack, an operator must craft a repository with specific directory structures. The repository must define a symbolic link entry whose target points outside the intended worktree directory, such as the localized .git metadata directory or system configuration folders.\n\nA second file entry is then added to the repository using a logical path nested within the symbolic link component. For example, if the symbolic link is named s and points to .git, the subsequent file is defined at s/config.\n\nWhen a vulnerable client performs a checkout, the application materializes the symbolic link s. When it proceeds to write s/config, the lexical parser permits the write, and the operating system follows the symbolic link to overwrite the repository's .git/config file.\n\nmermaid\ngraph LR\n A[\"Client Clones Malicious Repo\"] --> B[\"Checkout Writes Symlink 's'\"]\n B --> C[\"Checkout Processes Path 's/config'\"]\n C --> D[\"Lexical Check Approves 's/config'\"]\n D --> E[\"OS Resolves Symlink 's' to Target\"]\n E --> F[\"Attacker Payload Overwrites Target File\"]\n

The primary consequence of this vulnerability is unauthorized file modification and absolute file write capabilities within the security context of the user executing go-git. Because Git configurations control command execution parameters, this primitive easily leads to remote code execution.\n\nBy overwriting the repository's local .git/config file, an attacker can define malicious Git configurations such as custom core pagers, file system monitors, or post-checkout hooks. These configurations are executed automatically during subsequent Git operations performed by the host environment.\n\nThe vulnerability represents a CVSS score of 7.1, indicating high severity. The main limiting factor is the requirement of user interaction, as the victim must actively clone, pull, or checkout the malicious repository to trigger the exploit.

The definitive remediation for CVE-2026-71556 requires updating the go-git library to a patched version. Maintainers have released versions 5.19.2 and 6.0.0-alpha.5 to address the flaw across affected release branches.\n\nWhere immediate patching of the underlying library is impractical, operational mitigations should be applied. Deploying Go applications within ephemeral containerized environments ensures that out-of-bounds writes do not impact the underlying host filesystem or modify persistent configuration files.\n\nAdditionally, development teams can integrate static analysis tools such as govulncheck into build pipelines. This automated scanning flags instances of vulnerable go-git versions within the compiled binaries before deployment.