GHSA-HC8V-WWC9-VGXM
Vulnerability from github – Published: 2026-08-07 16:38 – Updated: 2026-08-07 16:38Impact
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. :1st_place_medal: We would also like to thank @HughLewis20, who independently reported the same issue while a fix was already in progress.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.19.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/go-git/go-git/v5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.19.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.0.0-alpha.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/go-git/go-git/v6"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.0-alpha.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71556"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-07T16:38:15Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Impact\n\nA symlink traversal issue in `go-git` could allow worktree operations to modify files outside the intended worktree path.\n\nThe `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.\n\nAs a result, a path that is safe when evaluated as a string could still resolve into the repository\u0027s Git metadata directory. For example, if `s` is a symbolic link to `.git`, writing to `s/config` would modify `.git/config`.\n\nA 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.\n\nExploitation 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.\n\nApplications using `storage/memory` for their Storer, or `go-billy/memfs` for their `Worktree`, are not affected by this vulnerability.\n\n## Patches\n\nThe issue has been addressed by making the worktree filesystem wrapper a symlink-safe boundary.\n\nWorktree 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.\n\nUsers of filesystem-backed worktrees should upgrade to a patched version.\n\n### Credits\n\nThanks to @kodareef5 for reporting this issue and working with the go-git security team toward its resolution. :1st_place_medal: \nWe would also like to thank @HughLewis20, who independently reported the same issue while a fix was already in progress.",
"id": "GHSA-hc8v-wwc9-vgxm",
"modified": "2026-08-07T16:38:15Z",
"published": "2026-08-07T16:38:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/security/advisories/GHSA-hc8v-wwc9-vgxm"
},
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/commit/008a78f2dd86f52544ddff8b8e8ddeecdf3f7aab"
},
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/commit/661d1c7f101d34e002a3cfcf8dbea5b7421d07ac"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-git/go-git"
},
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/releases/tag/v5.19.2"
},
{
"type": "WEB",
"url": "https://github.com/go-git/go-git/releases/tag/v6.0.0-alpha.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "go-git: Worktree operations may follow symlinks"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.