Impact
A symlink traversal issue in go-git could allow worktree operations to modify files outside the intended worktree path.
The worktreeFilesystem wrapper rejected dangerous path strings, including paths containing .git, parent-directory components, or control characters. However, it did not prevent filesystem operations from following symbolic links that were already present in the worktree.
As a result, a path that is safe when evaluated as a string could still resolve into the repository's Git metadata directory. For example, if s is a symbolic link to .git, writing to s/config would modify .git/config.
A symbolic link at the final path component could also be followed. For example, if s points directly to .git/config, opening s for writing with truncation could overwrite the repository configuration.
Exploitation requires an attacker to be able to introduce or control a symbolic link in the worktree and cause the application to perform a write through that path.
Applications using storage/memory for their Storer, or go-billy/memfs for their Worktree, are not affected by this vulnerability.
Patches
The issue has been addressed by making the worktree filesystem wrapper a symlink-safe boundary.
Worktree operations now reject paths where an existing symbolic link in any path component could cause the operation to escape the intended worktree location, including symbolic links at the final component.
Users of filesystem-backed worktrees should upgrade to a patched version.
Credits
Thanks to @kodareef5 for reporting this issue and working with the go-git security team toward its resolution. 🥇
We would also like to thank @HughLewis20, who independently reported the same issue while a fix was already in progress.
References
kodareef5 Reporter
HughLewis20 Reporter
Impact
A symlink traversal issue in
go-gitcould allow worktree operations to modify files outside the intended worktree path.The
worktreeFilesystemwrapper rejected dangerous path strings, including paths containing.git, parent-directory components, or control characters. However, it did not prevent filesystem operations from following symbolic links that were already present in the worktree.As a result, a path that is safe when evaluated as a string could still resolve into the repository's Git metadata directory. For example, if
sis a symbolic link to.git, writing tos/configwould modify.git/config.A symbolic link at the final path component could also be followed. For example, if
spoints directly to.git/config, openingsfor writing with truncation could overwrite the repository configuration.Exploitation requires an attacker to be able to introduce or control a symbolic link in the worktree and cause the application to perform a write through that path.
Applications using
storage/memoryfor their Storer, orgo-billy/memfsfor theirWorktree, are not affected by this vulnerability.Patches
The issue has been addressed by making the worktree filesystem wrapper a symlink-safe boundary.
Worktree operations now reject paths where an existing symbolic link in any path component could cause the operation to escape the intended worktree location, including symbolic links at the final component.
Users of filesystem-backed worktrees should upgrade to a patched version.
Credits
Thanks to @kodareef5 for reporting this issue and working with the go-git security team toward its resolution. 🥇
We would also like to thank @HughLewis20, who independently reported the same issue while a fix was already in progress.
References