#Forty-two repos. Two hundred thirty-six branches. Forty-six minutes.

On June 5, 2026, a threat actor used a single compromised GitHub account to push malicious commits across 42 repositories and 236 branches in the Microsoft, Azure, and Azure-Samples GitHub organizations. The entire operation took less than an hour.

This wasn't a fake package with a typosquatted name. This wasn't a lookalike org. This was malicious code committed directly to repositories owned by Microsoft. The real Microsoft. The repositories your team pulls from when building Azure integrations. The sample code your developers copy when standing up new services.

The malicious commits were identified and contained the same day. As of this writing, no evidence has surfaced that the poisoned code reached compiled artifacts or package registries. But the window was open. And if any automated system, mirror, CI pipeline, or developer happened to pull from those repos during that 46-minute window, they pulled malicious code from a source they had every reason to trust.

#This is TeamPCP. Again.

The attack has been attributed to TeamPCP, the same financially motivated group that's been running the most aggressive supply chain campaign of 2026. They compromised TanStack (12 million weekly npm downloads). They trojanized a VS Code extension with 2.2 million installs. They backdoored a security scanner's Jenkins plugin. They breached GitHub's own internal repositories.

Now they've pushed code directly into Microsoft's public GitHub organizations.

The pattern is consistent with what we've tracked all year. The injected payloads follow the cluster's established credential-harvesting playbook: targeting AWS, Azure, and GCP cloud identities plus CI/CD secrets. The speed and scale (42 repos, 236 branches, under an hour) is consistent with pre-staged automation using stolen credentials, not a human clicking through the GitHub UI.

And the credentials that made this possible? Those were likely stolen in a prior wave. That's how the worm works. Each compromise feeds the next one.

#The trust problem is the real problem.

Here's what makes this different from a poisoned npm package or a malicious PyPI upload.

When a new package shows up on npm with a weird name and zero downloads, your security tools flag it. When a package from an unknown author shows up in a pull request, a careful reviewer catches it. The entire security model around open-source dependencies assumes that the source matters. You check who published it. You check which organization owns the repo. You look for the blue checkmark, the Microsoft logo, the org badge.

On June 5, the source was Microsoft. The org was Azure. The repos were legitimate, established, widely-used repositories. Every signal your team uses to evaluate trust said "this is safe."

And for 46 minutes, it wasn't.

This is the supply chain equivalent of finding out your bank's ATM was dispensing counterfeit bills. The bills look real. The machine is real. The bank is real. But the output can't be trusted, because someone compromised the machine.

#What this means for your business.

You might not think you pull code from Microsoft's GitHub. You probably do.

Azure SDKs and sample code. If your development team builds on Azure (and many Chicago businesses do), they pull libraries, reference implementations, and sample code from these exact organizations. That code goes into your applications, your infrastructure, your deployment pipelines.

Automated dependency updates. If your CI/CD pipeline or developer tools automatically pull the latest from a GitHub repo (not just from npm, but directly from GitHub via git submodules, direct clones, or GitHub Actions references), you could pull poisoned code without any human reviewing it.

Developer trust habits. Developers copy code from Microsoft repos all the time. Stack Overflow answers link to Azure-Samples. Internal wikis reference Azure SDK examples. If a developer grabbed code from one of the 42 affected repos during the window, that code is now in your codebase.

Mirrors and forks. If your organization mirrors Microsoft repos internally (common in enterprises with air-gapped environments), and the mirror synced during that window, the malicious code is inside your network.

#What to do.

1. Check if you pulled from affected repos on June 5.

If your team works with Azure SDKs or Microsoft open-source projects, check your git logs, CI/CD pipeline runs, and deployment timestamps from June 5, 2026. If anything pulled from the Microsoft, Azure, or Azure-Samples GitHub organizations during that day, verify the commit hashes against the known-good state.

`bash

#Check your recent git pulls for Azure/Microsoft origins

git log --all --oneline --since="2026-06-05" --until="2026-06-06" | head -20

git remote -v | grep -i "azure\|microsoft"

`

2. Enforce branch protection rules on your own repos.

The fact that a single compromised account could push to 236 branches across 42 repos means branch protection was either not enforced or was insufficient. On your repositories:

• Require pull request reviews before merging (minimum 2 reviewers for critical repos)
• Require status checks to pass
• Disable direct pushes to main/production branches
• Require signed commits

This doesn't prevent account compromise, but it prevents a single compromised account from pushing code without review.

3. Audit your GitHub org membership and OAuth grants.

Go to your GitHub organization settings. Look at every member, every outside collaborator, every OAuth app, and every GitHub App with access. Ask:

• Does this person still work here?
• Does this app still need access?
• What permissions does this integration have?

Remove anything you can't justify. Every account with write access is an account that could be compromised.

4. Rotate tokens tied to Microsoft/Azure repos.

If any of your developers have PATs or SSH keys that interact with the affected organizations, rotate them now. TeamPCP's entire model is credential harvesting and reuse. A token that touched a compromised repo is a token you should assume is compromised.

5. Set up alerts for off-hours mass-commit activity.

The attack hit 42 repos in 46 minutes. That's the kind of automated burst that should trigger an alert in any monitoring system. Configure your GitHub audit log or SIEM to flag:

• Commits to multiple repos from a single account in a short window
• Push activity outside business hours
• Push activity from unexpected IP ranges or geolocations

`bash

#Monitor your org's audit log for bulk push events

gh api /orgs/YOUR-ORG/audit-log?phrase=action:git.push --paginate | head -50

`

6. Stop trusting code based on who published it.

This is the hardest one. The entire ecosystem is built on trust signals: organization badges, verified publishers, provenance attestations. TeamPCP has now compromised every layer. They've forged provenance attestations (Wave 2). They've published from legitimate accounts (Waves 1-6). They've pushed to legitimate organizations (this attack).

The only defense that actually works is verification at the point of consumption. Pin to specific commit hashes, not branches. Use lockfiles with integrity checksums. Review diffs before pulling updates. Treat every dependency update as untrusted code, regardless of the source.

#The pattern is clear.

In March, TeamPCP compromised npm packages. In May, they compromised VS Code extensions and Jenkins plugins. They breached GitHub itself. Now they're pushing code directly to Microsoft's repositories.

Each wave is bolder than the last. Each wave uses credentials stolen in the previous one. And each wave exploits a different layer of trust that the ecosystem depends on.

Your defenses can't be "we only use code from reputable sources." Reputable sources are the target now.

#Further reading

• Deepwatch Advisory: GitHub Repos Compromised via TeamPCP - primary source
• VentureBeat: 3,800 Repos Stolen, Poisoned VS Code Extension - broader campaign coverage
• GitHub: Managing Branch Protection Rules - enforce review requirements
• GitHub: Audit Log - monitor push activity
• Sigstore - software artifact signing and verification