GitHub Won't Fix Flaws Fueling the Shai-Hulud Worm

When researchers from Deep Specter Research discovered two design flaws GitHub was using, they did what responsible disclosure demands: filed formal vulnerability reports through GitHub's official HackerOne bug bounty channel. GitHub closed both reports as ineligible. Three weeks later, the Shai-Hulud supply-chain worm has 516 malicious packages live across five package ecosystems — and the flaws that help it hide are still wide open.

Key Takeaways

• Deep Specter Research filed two formal HackerOne vulnerability reports against GitHub in 2026; both were closed as "ineligible" and "not presenting a security risk."
• Shai-Hulud exploits commit timestamp backdating and author impersonation to make malicious code appear as routine, years-old edits from trusted engineers.
• As of June 16, 2026, the worm has produced 516 malicious packages across npm, PyPI, RubyGems, and two additional ecosystems, with 1,729 credential-storage repositories still live on GitHub.
• GitHub's Events API records the real push account, but that data expires from public view after approximately 90 days — long enough for most infections to go undetected before evidence disappears.
• GitHub's recommended mitigations (GPG/SSH signing and Vigilant Mode) are both opt-in features that the vast majority of developers have never enabled.

What Are the Two Flaws GitHub Refused to Fix?

The first flaw is commit timestamp manipulation. GitHub allows anyone pushing code to set the timestamp of their commit to any date they choose — last week, last year, or 2019. The Shai-Hulud worm uses this to make freshly injected malicious code look like a routine edit from years earlier. Automated security scanners that analyze recent changes to a repository skip right over it.

GitHub's position: commit timestamps are client-supplied metadata by design. The real problem, GitHub told Deep Specter, was the compromised developer credentials used to push the code in the first place. Technically, that is not wrong. Practically, it ignores why backdating amplifies the damage.

The second flaw is commit author impersonation. Git itself has no mechanism for verifying who wrote a commit — the name, email, photo, and displayed username are all freely settable by whoever runs git commit. GitHub renders these fields as if they represent confirmed identities. The platform never verifies them. Shai-Hulud variants use this to attribute malicious additions to well-known, trusted engineers on a project.

GitHub's position: author impersonation is inherent to git as a version control system, listed as a known ineligible finding in the bug bounty program documentation. GitHub pointed researchers toward GPG and SSH commit signing and its opt-in Vigilant Mode feature as existing mitigations.

How Shai-Hulud Chains Both Flaws Together

The worm, attributed to the TeamPCP cybercrime group, does not rely on either flaw in isolation. Once inside a compromised developer account, the attacker adds a malicious dependency or injects a credential-harvesting payload into the repository. The commit author field is set to a senior engineer on the project. The commit timestamp is set to eighteen months ago. The commit message reads something like "fix: update transitive dep versions."

From the outside, this looks like a maintenance commit made long before any security incident was reported. Historical scanners find nothing suspicious. Code review tools show a trusted name. The change sits quietly, and the next package release ships the payload.

The real push account — the attacker's actual GitHub account — is technically recorded in GitHub's Events API. But that data expires from public view after approximately 90 days. By the time an organization detects the compromise, the paper trail is often gone. This dynamic is documented in similar North Korean supply chain attacks through npm packages, which operated on a smaller but structurally identical pattern.

What Does the Current Damage Look Like?

Deep Specter's June 16, 2026 count: 516 malicious packages live across npm, PyPI, RubyGems, and two additional package registries. More than 3,000 repositories affected. Over 200 developer accounts compromised. There are 1,729 throwaway repositories on GitHub right now that exist solely to store stolen credentials. Of those, 151 repositories are still actively serving malicious payloads.

TeamPCP made this worse in May 2026 by publishing the full Shai-Hulud source code to GitHub itself, posting a $1,000 XMR bounty challenge that triggered a wave of copycat variants. Notable projects confirmed affected include TanStack, the LiteLLM package, and repositories belonging to Red Hat and the European Commission.

Why GitHub's Defense Misses the Point

GitHub's recommendation is technically accurate. GPG and SSH commit signing, combined with Vigilant Mode, would make both evasion techniques much less effective. The problem is the baseline: Vigilant Mode is an opt-in setting buried in account security preferences. GPG signing adoption among open source contributors remains well under 10% of commits on public repositories.

A trust signal that requires opt-in is not a default trust guarantee. GitHub displays author names, photos, and usernames in a UI that implies verification. Nothing in that interface tells a reviewer that the displayed identity is entirely unconfirmed. That gap between what the interface implies and what the platform actually verifies is precisely what Deep Specter flagged — and what GitHub declined to address.

What Developers Should Do Right Now

GitHub will not change these behaviors in response to Deep Specter's reports. The defensive surface is on the developer side:

Enable Vigilant Mode. Go to GitHub Settings → SSH and GPG keys → turn on Vigilant Mode. This flags any commit attributed to your account that lacks a valid signature with an "Unverified" badge.

Require signed commits on repositories you maintain. GitHub's branch protection rules allow you to require commit signatures as a merge condition. For any repository that ships to a package registry, this should be non-negotiable.

Audit against the Events API before merging. The Events API records the actual push account. Before merging a commit that modifies dependency declarations or CI/CD configuration, verify the push account matches the expected contributor. Do this within the 90-day window before the data expires.

Treat unusual commit timestamps as a red flag. A commit dated six months ago appearing in a pull request opened today is not normal. It warrants close inspection.

Monitor published packages for unexpected versions. Services like OpenSSF's package analysis publish feeds of newly flagged malicious packages. Subscribe to alerts for ecosystems your projects depend on.

The Shai-Hulud campaign will keep spreading as long as compromised accounts can push backdated, impersonated commits that evade historical scanners. GitHub has declined to narrow that attack surface. The responsibility has landed squarely on the developers building and maintaining the packages the rest of the ecosystem depends on.