Microsoft's Open Source Tools Were Poisoned to Steal AI Developers' Credentials

Summary

Microsoft cut off access to dozens of its own open source projects hosted on GitHub after attackers apparently breached them and injected password-stealing malware into the code. Per TechCrunch, many of the affected projects relate to Microsoft’s cloud service Azure, and a notable cluster are tools developers use alongside AI coding apps: the report names Claude Code, Gemini’s command line interface, and VS Code. Security firm Cloudsmith and the community malware-analysis site OpenSourceMalware, among the first to flag it, said the malicious code stole users’ passwords and other sensitive credentials when the compromised tools were opened inside an AI coding app.

The judgment here is blunt: the attackers didn’t touch a model or an algorithm. They touched the tools an AI engineer imports, npm installs, and runs in a terminal every single day. The target wasn’t the frontier of the stack; it was the most routine part of it. A developer extends implicit trust to dozens of unremarkable dependencies daily, and an attacker only needs to poison one that gets pulled often to land inside your machine. Microsoft confirmed it removed the repos, calling it a temporary step “as we investigated potential malicious content,” with some already restored after review and others possibly staying offline while work continues.

What happened

The shape of the incident, per TechCrunch: attackers breached Microsoft’s open source projects on GitHub and planted credential-stealing code in them. A substantial share of these projects center on Azure and on components developers use with AI coding tools. The trigger isn’t the alarmist “download equals compromise.” It’s that when a user opened the tampered tools inside an AI coding app, the malicious logic ran and exfiltrated passwords and credentials to the attackers. The report is explicit that it’s not immediately known how many people downloaded the affected tools. That’s an honest unknown, not a number being softened.

There is one hard, visible figure on scale. When you try to load the affected project pages, GitHub returns a notice that at least 70 of Microsoft’s projects have been “disabled,” reading “Access to this repository has been disabled by GitHub Staff due to a violation of GitHub’s terms of service.” Microsoft spokesperson Ben Hope told TechCrunch the company notified “a small number of customers who may have pulled down content from the affected repositories,” and said that if anything further surfaces requiring customer action, it will reach out directly through established support channels. Asked for the specific number of customers affected, Microsoft did not immediately provide one.

Pause on that 70. It is not a victim count. It’s the number of disabled repositories, and those two get conflated constantly while meaning entirely different things. Seventy disabled repos tells you how wide the contamination was and how large the cleanup is, not that 70 users got hit. The actual victim scale (how many pulled the code, how many credentials leaked) is, per the report, unknown, and Microsoft hasn’t disclosed it. Reading “70 repos pulled” as “70 victims” or “700K downloads” is inventing data the source doesn’t contain. When you assess your own exposure, the question is “did I pull anything from these repos,” not the repo count.

One more detail sets the character of this event. Per Ars Technica, this is Microsoft’s second known open-source breach in recent weeks: in mid-May, researchers said Microsoft’s open source project Durable Task (a tool that helps developers build apps) was hacked. OpenSourceMalware described the latest incident as a “re-compromise” of Durable Task, suggesting Microsoft may not have fully evicted the attackers the first time, or that this is an entirely new, distinct breach. Either reading is unflattering: leftover access that wasn’t cleaned out, or an asset attackers now treat as a reusable entry point.

Why it matters

Place the event in its trend first. The report calls it the latest in recent months of attackers breaching widely popular open source projects to plant malware on the large number of users who have that code installed. These are “supply chain” attacks because they target code reused across many software products, or used by a specific kind of user, and the report names the calculus directly: such users “sometimes have access to cloud systems and large amounts of customers’ data,” which makes them advantageous to hack. That sentence is the core of the whole story.

Translate it into an AI engineer’s reality: your dev machine is not an ordinary computer. It very likely holds long-lived cloud credentials, pull/push tokens for model registries, production database connection strings, CI deploy keys, and a row of API keys that spend real money (model inference, vector stores, assorted SaaS). What an attacker steals is never the abstract “password.” It’s the permissions behind it: the ability to spin up compute, move model weights, and reach production data. The AI engineer’s machine is becoming a uniquely high-permission target, and one successful hit pays off far more than compromising an ordinary office laptop.

It matters, too, because it punctures a trust assumption most teams quietly run on. The report deliberately notes that solo open source maintainers being targeted isn’t uncommon, sometimes through long campaigns to earn a maintainer’s trust, but that a tech giant like Microsoft, with the resources to defend against such attacks, getting breached is rare. A lot of teams score supply-chain trust by source. Packages from Microsoft’s or Google’s official org are treated as more trustworthy by default and audited more loosely. This event removes that default. Supply-chain trust shouldn’t rest on “who published it” but on “this version, verified by me.” When a highly trusted source is breached, everyone downstream who outsourced their trust to it is exposed at once.

Builder impact

First, move supply-chain auditing from “run once before release” to “continuous, with versions pinned.” The lesson isn’t “stop using Microsoft’s packages.” It’s “don’t skip verification just because it’s Microsoft.” Concretely: lock dependencies to exact versions with hash integrity (lockfile + integrity) so a quiet re-publish can’t slip in without your knowledge; pin critical dependencies rather than auto-tracking latest; add a dependency-diff review in CI so a new or version-bumped dependency gets a human’s eyes. This incident being described as a re-compromise of Durable Task means “this package was fine last time” is not a reason to skip the check this time.

Second, re-rack every credential on your dev machine and CI by least privilege. If the attacker’s goal is credentials, the defense should center on “even if this machine is owned, the permissions the attacker can grab are as small as possible.” In practice: don’t leave long-lived production keys sitting on a dev box; fetch cloud credentials short-lived and on demand rather than baking them into env vars or a permanent ~/.aws/credentials; split model-registry and package-registry tokens into read-only pull and writable push, and hand out only read for daily work; scope CI deploy permissions to specific repos and environments instead of one god-token that can touch everything. Least privilege won’t stop a breach, but it sets the blast radius, and “credential theft” is the disaster category here precisely because too many credentials were over-permissioned and long-lived.

Third, treat key rotation as routine, not as post-incident scramble. If you recently pulled content from the affected Microsoft repos (the report says Microsoft proactively notified “a small number” of such customers), the safe move is to assume those credentials may have leaked: rotate every token and password within reach of that machine, especially cloud, model registries, production databases, and billable API keys. More important, make rotation a habit: rotate on a schedule, and be able to revoke-and-reissue in one motion when a credential leaks, so any future incident is met with “rotate everything” rather than “lose everything.” Set spend and usage alerts on billable API keys too, since after credential theft an abnormal bill is often the first signal to surface.

Fourth, add observability for the act of credentials being read. The frightening part of “open a tool in your terminal and your passwords are gone” is that it’s silent. What builders can do is make silent visible: monitor abnormal reads of credential files, .env, and key directories; monitor abnormal outbound network connections from dev machines and CI (credentials have to be exfiltrated somewhere); enable login and anomalous-behavior alerts on critical accounts. Detection doesn’t replace prevention, but it shrinks “when did we find out” from weeks to hours, and for supply-chain attacks that time delta is the size of the loss.

What to ignore

Don’t ignore that 70; read it correctly. As above: 70 is the disabled-repo count, not victims, and not downloads. The right reaction is to cross-check your own dependency manifest and pull history, not to extrapolate “how many people in the industry got hit” from it. The source contains no such figure, and any conversion is fabricated.

Ignore the overreaction that “Microsoft got hacked, so Microsoft’s stuff is unusable now.” This was rare precisely because a company with the resources to defend was still breached, but the conclusion isn’t “abandon the Microsoft ecosystem.” That’s neither realistic nor a fix, because the next breached source could be any highly trusted one. The conclusion is to swap “trust the source” for “trust the verified version,” a change that applies to all supply-chain dependencies and has nothing to do with whether it’s Microsoft.

Ignore the embellishment about “nation-state APT, some 0day, some CVE.” As of the report, the public facts are: attackers breached Microsoft’s open source projects, injected credential-stealing code, at least 70 repos were disabled, the victim scale is unknown, and this is suspected to be a re-compromise of Durable Task. Attribution, vulnerability identifiers, and specific attack-technique details aren’t in the source. Until those are confirmed, spending energy on “cleaning up your own supply chain and credentials per the four points above” is more useful than chasing who the attacker is. What you control is your own blast radius, not someone else’s intent.

Technical takeaway

This incident puts the most fragile link in supply-chain trust on the table: a developer’s trust in dependencies is transitive, and transitive trust is undefended by default. You trust Microsoft, so you trust the package Microsoft publishes, so you open it in an AI coding app without a second thought and hand it execution rights, in an environment that holds your credentials. All an attacker needs is to breach one upstream point on that chain. The Durable Task re-compromise underlines that a breached asset, if not fully cleaned, becomes a reusable entry point.

The engineering countermeasures have a clear priority order. Do the blast-radius work first, because it holds even after you’re already compromised: least-privilege, short-lived, quickly-revocable credentials on dev machines and CI. Then shorten the dependency trust window: lockfile plus integrity to pin versions, human review for critical-dependency updates, no blind tracking of latest. Last, add observability: monitor abnormal credential-file reads and outbound connections, set spend alerts on billable keys. The relationship between the three layers is plain: prevention lowers the odds of compromise, least privilege sets the cost of compromise, detection sets how fast you know. None is perfect, but stacked, they turn the next incident of this kind from “lose your key vault” into “rotate everything and finish by end of day.”

Sources

1. Microsoft's open source tools were hacked to steal passwords of AI developers / news
2. Hacker News discussion (551 points) / hn

No official primary source available; this analysis is based on reliable secondary reporting (named outlets, cross-confirmed).