Git Heap Buffer Overflow via GIT_PUSH_OPTION_COUNT (CVE-2...

CVE-2022-39260 is a heap buffer overflow in Git that stems from an integer overflow while parsing the GIT_PUSH_OPTION_COUNT environment variable. The bug lives in the code path that git shell — the restricted login shell many hosting platforms use to give SSH users push/pull access without a full interactive shell — uses to reconstruct push options before handing control to git receive-pack. An attacker who can reach that code path with a crafted GIT_PUSH_OPTION_COUNT value can corrupt heap memory, and Git projects treated the flaw as serious enough to ship a coordinated point release across nine still-supported version lines. If your infrastructure runs git shell for restricted SSH access — a common pattern behind self-hosted Git servers, gitolite setups, and custom GitLab/Gitea deployments — this CVE deserves a look at your patch level.

What CVE-2022-39260 actually does

Git supports "push options" — arbitrary strings a client can send alongside git push that a server-side hook can inspect (think git push -o skip-ci or -o merge_request.create). To transmit these, the client sets GIT_PUSH_OPTION_COUNT to the number of options, then populates GIT_PUSH_OPTION_0, GIT_PUSH_OPTION_1, and so on for the receiving process to read back.

The vulnerable code trusted GIT_PUSH_OPTION_COUNT as an attacker-influenced integer without adequately bounding it before using it in size and offset calculations. Feeding it a sufficiently large value triggers an integer overflow, which in turn causes the code to under-allocate or mis-index a buffer on the heap. The result is a classic heap overflow: memory gets written past the end of its intended allocation, corrupting adjacent heap state. Depending on heap layout and platform, that corruption can crash the process (denial of service) or, in the worst case, be leveraged toward remote code execution.

The practical attack surface is git shell sessions that process push-option-bearing requests — i.e., a party who can already reach a restricted git shell account (for example, someone with an SSH key scoped only to git push/git-receive-pack) can use this bug to step outside the boundaries that restricted shell was supposed to enforce. That makes it particularly relevant for multi-tenant or restricted-access Git hosting, where "you can push to this one repo" is not supposed to mean "you can corrupt server memory."

Affected versions and components

The flaw is in Git core (the git command-line tool and its git shell/receive-pack push-option handling), not in a third-party dependency. The Git project's advisory identifies the vulnerability as present in versions prior to the fixed releases below, and it was patched simultaneously across every maintained release branch at the time:

• 2.30.6
• 2.31.5
• 2.32.4
• 2.33.5
• 2.34.5
• 2.35.5
• 2.36.4
• 2.37.4
• 2.38.1

Any Git installation older than the matching fixed version in its release line is considered vulnerable. Because Git ships as the underlying engine for countless CI runners, build agents, container base images, IDE integrations, and Git-hosting products, the practical exposure extends well past developer laptops — it touches build infrastructure and any service that shells out to git to service push requests.

CVSS, EPSS, and KEV context

CVE-2022-39260 was published alongside a sibling advisory, CVE-2022-39253 (a separate, unrelated issue involving local clones of repositories containing symlinks), in Git's October 18, 2022 security release. NVD rates CVE-2022-39260 as High severity, reflecting the memory-corruption impact once the overflow is triggered. As of this writing, the vulnerability does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and public EPSS scoring for this CVE has remained low — consistent with a bug that requires an attacker to already hold restricted git shell access rather than one that's exploitable from an anonymous network position. That access requirement matters for prioritization: it's not a "patch tonight, internet-facing RCE" situation for most environments, but it is a meaningful privilege-escalation risk anywhere restricted Git-only accounts are handed out to less-trusted parties.

Timeline

• Discovery: The issue surfaced from a source-code security audit of core Git commissioned as part of the broader push by major Git hosting providers to harden the Git toolchain, alongside other hardening work landing in the same release cycle.
• October 18, 2022: The Git project publicly disclosed CVE-2022-39260 (and CVE-2022-39253) and simultaneously released patched versions — 2.30.6, 2.31.5, 2.32.4, 2.33.5, 2.34.5, 2.35.5, 2.36.4, 2.37.4, and 2.38.1 — across all actively maintained branches.
• Post-disclosure: Downstream distributions (Linux distros, package managers, container base images) and Git hosting platforms that bundle their own Git binaries rolled out updated packages in the days and weeks following upstream's release, as is standard for coordinated Git security releases.

Remediation steps

1. Upgrade Git. Move to the fixed version matching your release line (2.30.6, 2.31.5, 2.32.4, 2.33.5, 2.34.5, 2.35.5, 2.36.4, 2.37.4, or 2.38.1 and later). If you're on an End-of-Life 2.2x branch or earlier, this is a good forcing function to move onto a supported line.
2. Audit every place git is installed, not just developer machines. CI/CD runners, build containers, base images, artifact-signing hosts, and any server invoking git shell for SSH-based access are all in scope. A stale Git binary baked into a golden AMI or container image two years ago is exactly the kind of asset this class of bug hides in.
3. Review restricted git shell deployments specifically. If you run gitolite, a custom SSH-only Git server, or any setup where users are handed keys scoped to git-receive-pack/git-upload-pack via git shell, treat this CVE as a priority: it directly targets that trust boundary.
4. Confirm the fix took, don't just trust the changelog. Run git --version on affected hosts post-patch and verify it matches or exceeds the fixed version for that branch.
5. Watch for anomalous GIT_PUSH_OPTION_COUNT values in logs if your Git server infrastructure logs environment or protocol-level data — an implausibly large count is a strong indicator of exploitation attempts, past or ongoing.
6. Track this as part of routine dependency and toolchain patching, not a one-off fire drill. Git security releases are infrequent but not rare, and the software supply chain risk from an outdated git binary sitting quietly in a CI image is easy to lose track of.

How Safeguard Helps

CVE-2022-39260 is a good illustration of why software supply chain security has to extend past application dependencies and down into the toolchain itself. A vulnerable Git binary sitting in a CI runner or a base container image doesn't show up in a typical package.json or requirements.txt scan — it hides in build infrastructure that teams often forget to inventory.

Safeguard's platform is built to close exactly that gap:

• Toolchain and build-environment visibility: Safeguard inventories the software running across your build agents, CI/CD pipelines, and container images — including core tools like Git — so a vulnerable version doesn't sit undetected in infrastructure that never gets a traditional dependency scan.
• Continuous CVE monitoring: When advisories like CVE-2022-39260 land, Safeguard correlates them against your actual environment in real time, flagging every asset still running an affected Git version instead of leaving that correlation to a manual spreadsheet exercise.
• Policy-based enforcement: Safeguard lets teams set guardrails that block deployments or CI runs from proceeding on toolchains with known-vulnerable components, turning "we should patch Git everywhere" into an enforced control rather than a hope.
• Prioritization grounded in exploitability: By pairing CVSS, EPSS, and KEV signal with your actual exposure (do you even run git shell for restricted access?), Safeguard helps teams focus remediation effort on the vulnerabilities that matter for their environment instead of chasing every CVE with equal urgency.
• Audit-ready evidence: For teams under SOC 2 or similar compliance obligations, Safeguard maintains the record of what was detected, when it was remediated, and how — turning incident response into documented, auditable process.

Vulnerabilities in foundational tools like Git are a reminder that supply chain security isn't just about the code you write — it's about everything that touches the path from commit to production. Safeguard is built to keep that entire path visible and enforced.