GitHub Pulls 73 Microsoft Repos After Shai-Hulud Worm Slips Back In

On June 5, developers building against Microsoft's GitHub organizations watched their pipelines fall apart. Workflows that had been running for months suddenly failed to resolve dependencies, and the most visible casualty was Azure/functions-action, the GitHub Action thousands of teams use to deploy Azure Functions. When the referenced repository disappeared, there was nothing left for the workflow to pull, so builds stalled and the support channels filled with confused engineers.

Microsoft had removed 73 repositories across its Azure, microsoft, Azure-Samples, and MicrosoftDocs organizations. The company contained the takedown in 105 seconds, but the ripple effect lasted considerably longer. Microsoft told BleepingComputer the repos were pulled over concerns they distributed "potential malicious content," while an early on-page message attributed the action to GitHub Staff acting on a "violation of GitHub's terms of service." A Microsoft representative in a community thread initially described it as "an internal management issue" with an investigation underway. Mixed messaging during a live incident is normal, but it left developers guessing about whether their own builds were compromised.

What actually happened

Multiple researchers connected the takedown to the Miasma/Shai-Hulud supply-chain campaign, a self-propagating worm that has been chewing through open-source package ecosystems for months. Security engineer Adnan Khan linked the June 5 Microsoft incident to the same Miasma activity that infected 32 of Red Hat's npm packages.

Software supply chain management firm Cloudsmith traced the path in a report this week. According to their analysis, the worm first hit the @redhat-cloud-services npm namespace by compromising a Red Hat employee's GitHub account. "By pushing unreviewed orphan commits to internal repos, the threat actors injected a minimal workflow that requested GitHub's OIDC tokens," the researchers wrote. Those tokens became the pivot point. The actor moved from Red Hat's npm packages into Microsoft's Azure environment on GitHub and the durabletask repository.

The Miasma variant specifically targeted AI coding tools, including Claude Code, Gemini CLI, VS Code, and Cursor. That choice is deliberate. AI coding assistants run with broad filesystem and credential access, often holding tokens for package registries, cloud providers, and source control in the same environment. A worm that lands inside a developer's AI tooling inherits a generous set of permissions without needing to phish anyone directly.

The cleanup that wasn't

The detail worth sitting with is the timeline. The OpenSourceMalware platform notes that the durabletask package on PyPI was already compromised in May, when the threat actor pushed three malicious versions: 1.4.1, 1.4.2, and 1.4.3. If the same repository in Microsoft's Azure organization was hit again in June, it suggests the May remediation never fully closed the door. The actor came back through a gap that the first cleanup missed. Microsoft has not confirmed that reading, and the connection remains the assessment of outside researchers rather than the company.

This is a recurring failure mode in supply-chain response. Pulling a malicious package version or rotating an obviously exposed credential feels like containment, but worms like Shai-Hulud plant persistence in workflow files, orphan commits, and stolen OIDC tokens that outlive the initial artifact. Rotate one token and miss another, and the intrusion simply resumes.

Where things stand for affected users

All 73 repositories have been restored and are considered clean and safe to use. Microsoft says it "temporarily removed some repositories as we investigated potential malicious content" and "notified a small number of customers who may have pulled down content from the affected repositories." The company added that it will continue investigating and reach out directly through established support channels if customer action becomes necessary.

If you run pipelines that reference Microsoft's Azure Actions or pulled the affected durabletask PyPI versions during the compromise window, treat any credentials those workflows touched as suspect. Rotating tokens after the fact costs little; assuming you were spared costs a lot if you weren't.

A pattern, not an isolated breach

The Microsoft takedown lands in the middle of a busy stretch for supply-chain attackers. Application security firm Socket reported a new Shai-Hulud attack over the weekend that used a fresh delivery mechanism. StepSecurity documented a separate Shai-Hulud campaign hitting Pythagora-io/gpt-pilot, an open-source AI developer tool with more than 33,700 GitHub stars and over 3,500 forks. Other recent waves have trojanized science-focused PyPI packages, compromised roughly 600 npm packages, and shipped signed malicious TanStack and Mistral npm packages. A missed token rotation after one of those TanStack attacks is what caused a Grafana breach.

The common thread across all of these is reach through automation. The worm does not need to compromise every maintainer. It needs one account with token access and a CI system willing to run unreviewed commits, then it propagates outward through the trust relationships that make open-source ecosystems work.

Practical defenses

The advice that holds up across this campaign is unglamorous and effective. Lock your project dependencies to specific, verified versions rather than floating ranges, so a freshly poisoned release cannot slide into your build automatically. Add a multi-day delay before adopting new package updates, which gives the broader community time to flag malicious versions before they reach you. The durabletask PyPI versions, for example, were identified as malicious; a cooling-off window would have caught them.

Test new builds in isolated environments that lack production credentials, so a worm reaching for OIDC tokens or registry secrets finds nothing useful. Audit your CI configuration for workflows that request broad token scopes, and treat any unreviewed orphan commit to an internal repo as the red flag it is, since that was the exact technique used against Red Hat. Finally, when you respond to an incident, assume persistence. Rotate every credential the compromised environment could have seen rather than just the one that looks exposed, because the gap between a partial cleanup and a complete one is precisely where Shai-Hulud keeps coming back.