Microsoft Pulls GitHub Repos After 73 Open-Source Projects Get Stealer-Spiked

Microsoft has confirmed it temporarily yanked several of its own GitHub repositories offline after an attacker managed to plant an information stealer inside 73 open-source projects tied to the company.

The cleanup is ongoing. Some repos are back. Others are still dark while the investigation, internally tagged Miasma, runs its course.

"Our priority is to protect customers and the broader ecosystem," a Microsoft spokesperson said, confirming the takedowns and the scope of the compromise.

What we know so far is narrower than the headline suggests. This is not a compromise of Windows, Azure, or any flagship product source tree. The affected projects sit in Microsoft's sprawling open-source orbit — the kind of utility libraries, samples, and tooling repos that get forked by developers who assume anything under a microsoft/ or adjacent org namespace is trustworthy by default.

That assumption is the actual attack surface.

We've seen this movie before. Stealer-in-the-repo is the GitHub-native cousin of typosquatted npm packages and poisoned PyPI wheels. The novelty here, if there is one, is the brand: when the malicious commit lands under a Microsoft-affiliated org, the social-engineering work is already done.

Microsoft has not yet publicly detailed the initial access vector. The plausible candidates are familiar to anyone who's covered software supply chain incidents for more than a week: stolen maintainer credentials, a compromised personal access token, a leaked GitHub App secret, or a phished contributor with write access. None of those would be a Microsoft-specific failure. All of them would be a reminder that an org with thousands of repos has thousands of credential blast radii.

The information stealer payload itself has not been fully characterized in public reporting. What matters for defenders right now is downstream exposure. If your build pipeline pulled from one of the affected repos between the compromise window and the takedown, you need to assume any developer machine or CI runner that touched the code is potentially in scope for credential theft.

A few practical moves while Microsoft sorts out attribution:

• Audit recent git clone and dependency pulls from Microsoft-org repos against the list of affected projects once it's published.
• Rotate any tokens, cloud credentials, or SSH keys that lived on machines that built or ran the suspect code.

This is the part of the supply-chain story the industry still hasn't solved. SBOMs tell you what's in your build. They don't tell you whether the upstream maintainer's laptop got popped last Tuesday.

Microsoft says more details are coming. Until the company publishes the affected repo list and the indicators of compromise, treat any recent pull from its open-source footprint with the same suspicion you'd apply to a random npm package with three stars and a suspicious postinstall script.