GHSA-w5pp-99ch-qj29

What it actually does

Affected go-git releases can panic or consume excessive CPU and memory while decoding attacker-controlled Git packfiles (.pack), pack indexes (.idx), or loose objects. The failure occurs in the library’s object-parsing path used during clone, fetch, open, and similar operations, aborting the host process or starving other work on the same node.

Why it matters to the business

Services that clone or inspect Git repositories—CI/CD systems, developer platforms, code review, and supply-chain scanners—can be taken offline by a single malicious repository, causing failed pipelines and availability outages. Impact is availability, not confidentiality or integrity. The issue is medium severity (CVSS 6.5), is not in CISA KEV, has no ransomware association, and has no public exploit maturity more than four months after publication, so residual risk is operational disruption rather than breach or ransomware.

How an attack unfolds

An attacker supplies Git object data that the go-git parser cannot handle safely: a malicious remote repository the victim clones or fetches, or tampered read-only pack/index/loose objects under a local repository’s .git/objects/pack/ directory. When an application on a vulnerable go-git release parses that data, the decoder panics or exhausts resources and the process becomes unavailable. Exploitation does not yield code execution or data theft by itself; it requires the victim to ingest untrusted Git objects, which is already a high-risk trust boundary (malicious remotes expose a broader class of risks beyond this issue).

How to fix it

Upgrade go-git to a patched module release listed in GHSA-w5pp-99ch-qj29 and on the module’s advisory/changelog, then rebuild and redeploy every binary that vendors or requires the affected module. Until upgraded, do not clone, fetch, or open repositories from untrusted remotes, and treat local .git/objects/pack/ as a trust boundary: restrict write access so unprivileged users and pipelines cannot replace pack or idx files. Process untrusted Git data in isolated, resource-limited sandboxes so a parser panic cannot take down the parent service.

How to confirm the fix worked

Inventory Go module graphs (go.mod/go.sum, SBOMs, go version -m on deployed binaries) for github.com/go-git/go-git and legacy gopkg.in/src-d/go-git paths still on unpatched versions. After upgrading, confirm the new module version is embedded in production binaries and regression-test clone/fetch/open against trusted repositories. Dependency scanners and Dependabot/advisory alerts for this GHSA should clear once patched versions are in use.

Typical attack path

1. Identify an application, CI worker, or tool that uses a vulnerable go-git release to clone, fetch, open, or otherwise parse Git data.
2. Place malformed pack, idx, or loose-object data where that application will read it—either by hosting a remote the target fetches or by replacing files under .git/objects/pack/ on a repository it opens.
3. Wait for the target to parse the untrusted Git objects.
4. The go-git parser panics or exhausts CPU/memory, denying service until the process is restarted or capacity is restored.

How to detect it

This flaw leaves availability artifacts rather than a distinct implant, and there is no associated KEV or named threat-actor campaign. Hunt for unexpected process crashes, OOM kills, or Go panics in services that clone, fetch, or open Git repositories, especially right after contact with a new or unusual remote. Review application stdout/stderr and container logs for panic stacks in go-git packfile, idxfile, or object-parsing packages; orchestrator events for crash-looping Git workers; host metrics for sudden CPU/memory spikes correlated with Git operations; and audit logs showing writes under .git/objects/pack/ or clones from unapproved remotes. Treat unexplained parser crashes while handling untrusted Git data as a possible availability attack unless a known-bad repository explains them.

• github.com/go-git/go-git
• github.com/go-git/go-git/plumbing/format/packfile
• github.com/go-git/go-git/plumbing/format/idxfile
• gopkg.in/src-d/go-git
• panic:
• fatal error: runtime: out of memory
• .git/objects/pack/
• .pack
• .idx

What your security team should do

• Inventory production services, CI runners, and developer tools that embed go-git and process repositories not fully under organizational control.
• Patch and rebuild those workloads even though this advisory is not in KEV and has no public exploit—Git-processing availability is a common operational dependency.
• Allowlist trusted remotes and ensure .git/objects/pack/ is not writable by untrusted users or pipelines.
• Run Git parsing in resource-limited isolation and alert on process crashes, OOM kills, and crash-loops of Git workers.
• Track GHSA-w5pp-99ch-qj29 until all go-git dependents are upgraded and verified in SBOMs and deployed binaries.