Skip to content
induwara.lk
Premium
Opinionsupply-chain-securityopen-sourcedeveloper-tools

Microsoft Repos Got Hacked. Your Dependencies Aren't Safe.

Hackers slipped password-stealing malware into dozens of Microsoft's own GitHub projects. Here's what a Sri Lankan dev on a free tier should actually do about it.

Induwara Ashinsana5 min read

Microsoft's open source repos got hacked to steal developer passwords, and the part that should worry you is not Microsoft. It's that if a company with that much security budget got hit through its own GitHub projects, the half-dozen random packages you pulled into your side project last week deserve a second look.

The story comes from TechCrunch (original report here), which covered Microsoft disabling at least 70 open source projects on GitHub after hackers injected credential-stealing malware. I'm not republishing their reporting. I want to talk about what it means for someone building on a learning budget in Sri Lanka.


🔍 What actually happened

According to TechCrunch, hackers compromised a batch of Microsoft's own open source tools and slipped in malware that steals passwords and sensitive credentials. The trigger was opening the compromised tools inside an AI coding application.

The affected projects spanned exactly the stack a lot of us use for free:

Affected area Examples named in the report
Azure cloud tooling Azure cloud service tools
AI dev tools Claude Code, Gemini CLI, VS Code
Background jobs Durable Task (a re-compromise from mid-May)

Key takeaway: The malware didn't break in through some exotic zero-day. It rode in through trusted, official-looking repositories that developers downloaded on purpose. The trust was the attack surface.

Microsoft spokesperson Ben Hope said the company "temporarily removed some repositories as we investigated potential malicious content." Some were restored after review, others stayed offline. Security firm Cloudsmith, the analysis site OpenSourceMalware, and 404 Media (which first reported it) were all involved in surfacing the problem. Ars Technica noted this was Microsoft's second breach in weeks.


⚡ Why this hits small teams harder than Microsoft

Microsoft can absorb this. It has an incident response team, customer notifications, and the headlines move on. You don't have any of that. If a poisoned package lifts your credentials, the first you'll hear of it is a surprise bill or a deleted database.

Here's the uncomfortable asymmetry:

  • Big company gets breached → press release, rotated keys, forensics, done.
  • Solo dev gets breached → drained cloud credits, leaked client data, no insurance, no PR team, possibly a personal liability.

If a vendor with a security org this large can ship a compromised repo, "it's an official package, it's fine" is not a security model. It's a hope.

For students and freelancers especially, the danger is concentrated. You're often logged into the same machine for your free Azure for Students credits, your client's repo, your personal email, and your bank's OTP app. One credential thief on that box reaches all of it.


🛠️ What I'd actually change in my workflow

You can't audit every dependency. Nobody can. But you can shrink the blast radius so one bad package doesn't own your whole life. This is what I do, and what I'd tell any junior dev to do:

  1. Pin versions. Stop auto-updating to latest. A lockfile is not optional. The mid-May Durable Task re-compromise is the lesson: a repo you trusted last month is not automatically the same repo today.
  2. Use scoped, short-lived tokens. Never put a long-lived admin token in an environment a random tool can read. A leaked token that can only deploy one project is a bad day. A leaked root key is a catastrophe.
  3. Never store passwords in plaintext anywhere. Not in .env committed by accident, not in a notes.txt. If you genuinely need to compare or fingerprint a secret, hash it first with a tool like our hash generator instead of pasting the raw value around.
  4. Keep one machine for client work, separate logins for personal stuff. Or at minimum, separate browser profiles. Credential stealers grab whatever the session can see.
  5. Read the token, don't trust the token. If a tool hands you a JWT and you're not sure what scopes it carries, decode it yourself with something like our JWT decoder before you wire it into anything.

Bottom line: You're not trying to be unhackable. You're trying to make sure that when something does get through, it can only reach one disposable thing instead of everything you own.


💡 The AI-coding-tool angle nobody wants to say out loud

The detail that stuck with me: the malware activated when developers opened the compromised tools inside their AI coding application. That's the new normal we're all rushing into. We point an AI agent at a repo, let it read files, run commands, and install dependencies, often with broad access to our machine.

That convenience is exactly what a credential stealer wants.

Old workflow AI-agent workflow
You read the README, then ran the install The agent installs and runs things for you
You saw each command before it executed Commands execute in a loop you skim
Limited file access Often broad read access to your project and env

I'm not telling anyone to stop using AI coding tools. I use them every day. But the right instinct is to treat an AI agent like a contractor you just met: give it the access it needs for this job, in a workspace where the worst case is recoverable, and not the keys to production.

The same automation that lets one developer ship like a team is the same automation that lets one poisoned dependency move at machine speed. Both directions scale.


🌐 What this means for you

If you're a student, a freelancer, or a two-person shop in Sri Lanka, you don't need an enterprise security program. You need three habits that cost you nothing:

  • Lock your dependency versions and update on purpose, not automatically.
  • Scope every credential so a leak is contained, not total.
  • Separate your environments so client work and personal logins don't share a session.

The Microsoft story isn't really about Microsoft. It's a reminder that the open source supply chain runs on trust, and trust is the one thing an attacker only has to break once. Build like that's already true, because for at least 70 repositories, it was.

Commentary based on reporting by TechCrunch, published 8 June 2026. Facts attributed to that report; analysis is my own.

#supply-chain-security#open-source#developer-tools

AI-assisted draft, reviewed and approved by Induwara Ashinsana before publishing. Sources are linked inline; if something here is wrong, tell me and it gets corrected.

IA

Induwara Ashinsana

Information Systems student at UCSC and Executive Director at Ryzera Technologies. Writes about software, AI, and what it means for builders in Sri Lanka.

About the author →

Keep reading