Security News GitHub dismissed security reports on flaws now exploited by supply-chain worm, researchers say

[Brownie2019]

Content source

https://therecord.media/github-dismissed-reports-shai-hulud-deep-specter

GitHub rejected two formal vulnerability reports identifying design flaws that researchers say are enabling variants of the Shai-Hulud supply-chain worm to infect and compromise hundreds of software packages and developer accounts worldwide.
The reports, submitted by threat intelligence group Deep Specter Research through GitHub’s bug disclosure channel on HackerOne, were both closed as ineligible and not presenting a security risk, despite the ongoing threat posed by the worm.
Although the hacking tool originated with the TeamPCP cybercrime group, copycat entities have emerged using slightly different versions since the original code was published in early May. Over the last few months, these variants have been linked to breaches at the European Commission, AI recruiting firm Mercor, the LiteLLM package, GitHub itself and Red Hat.
Deep Specter told Recorded Future News that its investigation, conducted using only public data, confirmed 516 malicious packages were currently live across five ecosystems including npm, PyPI and RubyGems, with more than 3,000 affected GitHub repositories and over 200 compromised developer accounts.
The figures were described as a floor by Deep Specter, which noted in a technical report that GitHub's code search does not index files above a certain size threshold, rendering the worm's primary payload — a roughly 4.6 MB obfuscated file — invisible to automated scanning.
The company said its first report to GitHub concerned how GitHub handles commit timestamps, allowing whoever pushes the code the freedom to backdate when they added it to a repository. Deep Specter said the worm uses this feature to make recently added malicious changes appear like routine edits from years earlier, evading defenses that look in a repository's history for recent suspicious activity.
GitHub told the researchers that commit timestamps are client-supplied metadata by design and that the underlying security issue was the compromised credentials used to push the code, not the timestamp.
Deep Specter’s second report concerned who was identified as the author of these commits. GitHub displays the name, photo and username of the authors as if they were confirmed, but in practice the fields are freely set by the attacker and never verified. The worm uses this to make malicious commits appear to have been made by trusted engineers who never touched the code.
GitHub told researchers that arbitrary author metadata is a property of the git version control system, not a GitHub vulnerability, and that its bug bounty program documentation explicitly lists commit author impersonation as a known ineligible finding.
The company pointed Deep Specter to GPG and SSH commit signing and its opt-in Vigilant Mode as available mitigations. The developers whose identities were forged in the Shai-Hulud campaign had not enabled those controls.
GitHub does record which account actually pushed each commit — data that cannot be forged — in its Events API, but does not display it on the commit page visible to reviewers. That record expires from public view after approximately 90 days. Deep Specter raised the security value of improving the visibility of these records, but GitHub described that as a feature request rather than a security fix.
As of June 16, Deep Specter said 1,729 throwaway repositories created by the worm to store stolen credentials remained live on GitHub, alongside 151 repositories still serving active malicious payloads — figures the company described as a snapshot of public data on that date.
Last week, Microsoft released fixes for more than 200 security flaws — the largest Patch Tuesday in the program’s history — in the latest sign of how artificial intelligence is reshaping the world of vulnerability discovery and mitigation.
It comes as Microsoft faces renewed criticism over its disclosure policies, with the company recently forced to clarify it had “no intention to pursue action” against security researchers after sparking outcry from the security community.
Researchers have repeatedly complained that the company has unjustly dismissed their vulnerability reports and, under the Biden administration, was described as presiding over a cascade of security failures allowing hackers to break into government systems.
Another researcher recently published a separate GitHub token-stealing exploit targeting Microsoft repositories in the same period, underscoring the breadth of credential-theft activity targeting the platform. The researcher made the exploit public due to their dissatisfaction with how Microsoft handled security reports.
Neither GitHub nor its parent company Microsoft responded to requests for comment.

 

[Bot]

What the quote is describing is largely an uncomfortable (but real) boundary between “a security vulnerability in GitHub” and “how git works by design,” and attackers are actively abusing that gap in supply-chain campaigns.

Why the two issues are hard to treat as “bugs”

• Backdated commit timestamps: In git, the “author date” and “committer date” are metadata provided by the client tooling at commit time. Hosting platforms typically display this metadata because it’s part of the commit object. If an attacker can push commits (stolen token/credential), they can also craft misleading dates.
• Commit author impersonation: The “author name/email” fields are also arbitrary metadata in git. A platform can add extra UI signals, but it cannot retroactively make unsigned git history “trustworthy” without cryptographic verification (signing) and policy enforcement.

That said, it’s also fair to argue that platforms can reduce reviewer deception by making “who actually pushed this” more prominent and long-lived, even if that’s categorized as a product/UX change rather than a bounty-eligible vulnerability.

Practical mitigations that actually move the needle

1) Require cryptographic trust for commits

• Org/repos: require signed commits (GPG/SSH/S/MIME) and block merges that aren’t verified.
• Individual devs: enable Vigilant mode so unsigned commits are clearly flagged in the UI.

2) Reduce the chance of credential theft becoming “push access”

• Enforce 2FA for org members.
• Prefer short-lived, least-privilege tokens; remove classic PATs where possible; rotate any token suspected exposed.
• Use branch protection + required PR reviews, and restrict who can push to protected branches.

3) Supply-chain hygiene (because packages are the real blast radius)

• Pin dependencies (and use lockfiles) and review diffs when updating, rather than floating to “latest.”
• Use Dependabot (or equivalent) but treat updates as code changes that need review.
• Add CI checks for suspicious additions (unexpected new build steps, install scripts, obfuscated blobs, new network calls, etc.). Attackers often rely on reviewers skimming.
• Consider provenance/signing for releases where applicable (e.g., SLSA-style attestations), especially for widely-consumed packages.

4) Reviewer guidance: don’t trust the “author” line

In any incident-response or suspicious PR/commit review, treat the displayed author identity as untrusted unless the commit is verified/signed. For high-value repos, “unsigned = untrusted” is the simplest rule that scales.

What you can take away from this thread

Even if GitHub is correct that these are properties of git rather than “vulnerabilities,” the threat is still very real: if attackers steal credentials, they can make malicious history look old and make commits look like they came from someone reputable. The reliable defenses are (1) preventing credential theft from turning into push access, and (2) requiring cryptographic verification so identity can’t be faked in reviews.

Sources

• Signing commits - GitHub Docs
• https://docs.github.com/authenticat...es-for-all-of-your-commits-with-vigilant-mode
• About protected branches - GitHub Docs
• About two-factor authentication - GitHub Docs
• REST API endpoints for events - GitHub Docs