A variant of the infamous Shai-Hulud worm has disrupted Microsoft’s GitHub repositories, breaking CI/CD workflows and raising fresh concerns about the speed and reach of modern software supply chain attacks.
The incident unfolded on June 5, when GitHub automatically took 73 Microsoft repositories offline in less than two minutes after detecting potential terms-of-service violations. Most of the affected repositories were under Microsoft’s Azure organization.
The disruption had an immediate downstream impact. Organizations around the world that relied on affected GitHub Actions suddenly saw their build and deployment pipelines fail.
One of the most visible examples was Azure/functions-action, the GitHub Action used to deploy Azure Functions. When that action stopped resolving, any workflow referencing Azure/functions-action@v1 could break.
The incident shows how fragile modern CI/CD ecosystems can be when trusted developer infrastructure is compromised or temporarily disabled.
From Shai-Hulud to Miasma
The activity has been linked to Miasma, a variant of the Mini Shai-Hulud worm.
Shai-Hulud-style attacks are dangerous because they spread through trusted software development channels, such as package registries, repositories, GitHub Actions, and developer tooling.
Earlier Shai-Hulud and Mini Shai-Hulud campaigns focused heavily on stealing developer secrets and cloud credentials. Miasma appears to follow that same logic but with a shift in delivery technique.
Instead of relying only on poisoned packages, the June 5 activity abused repository configuration files that execute when developers open compromised repositories using certain AI coding tools or integrated development environments.
This is an important evolution.
Attackers are moving toward the least-monitored trusted surfaces in the developer workflow.
Microsoft Repositories Taken Offline
Open Source Malware first reported the June 5 incident, noting that GitHub disabled 73 Microsoft repositories in an automated sweep.
The repositories were later restored after review, but the temporary removal still created real operational problems for downstream users.
GitHub Actions are not ordinary libraries. They run inside other organizations’ CI/CD pipelines.
That means when a widely used action disappears, workflows depending on it may fail immediately.
For organizations deploying Azure Functions, the removal of Azure/functions-action and related actions caused pipeline failures simply because the referenced action could no longer be resolved.
This highlights a major supply chain dependency problem: many organizations depend on external CI/CD actions that they do not control.
Link to Microsoft PyPI Package Compromise
StepSecurity connected the June 5 repository compromise to a previous incident involving Microsoft’s official durabletask Python SDK on PyPI.
On May 19, three poisoned versions of the package were published to PyPI. The package typically receives around 400,000 downloads per month.
The malicious versions were online for approximately 35 minutes before Microsoft removed them.
According to StepSecurity, the poisoned versions contained a modular cloud intrusion framework called rope.pyz. This framework was designed to steal secrets and credentials and could also deploy a destructive wiper in some regions.
The attacker had reportedly compromised real publishing credentials for an official Microsoft package and bypassed the repository’s build pipeline entirely.
That earlier incident is now considered part of the broader TeamPCP and Mini Shai-Hulud supply chain activity.
Reuse or Recompromise of Contributor Access
StepSecurity noted that a malicious commit in the June 5 attacks came from the same contributor account linked to the earlier Microsoft PyPI package compromise.
That raised several possibilities.
One possibility is that credentials were not fully rotated or revoked after the May 19 incident.
Another is that the account was compromised again through the worm’s own propagation loop.
A third possibility is that attackers used another contributor token and spoofed commit author metadata through GitHub’s Git Data API.
StepSecurity’s leading assessment was that re-compromise through the worm’s propagation loop may have occurred, possibly combined with incomplete credential rotation.
This is a key lesson for incident response: after a supply chain compromise, partial credential rotation is not enough. Every related token, session, key, and publishing permission must be reviewed.
AI Coding Tools Become the New Attack Surface
One of the most important details in this incident is the malware’s focus on AI coding tools.
StepSecurity reported that the credential-stealing malware targeted:
- Anthropic Claude Code
- Google Gemini CLI
- Cursor
- Visual Studio Code
Instead of poisoning only package manager install hooks, the attackers planted configuration files for these tools and IDEs.
Those files could execute code when a developer opened a compromised repository.
That means a developer did not necessarily need to install a package or run a build. Simply opening a cloned repository in the wrong environment could activate the malicious payload.
This is a major shift in supply chain attacks.
Defenders have spent years monitoring package registries, dependency manifests, install scripts, and CI/CD pipeline execution. But AI coding agents and IDE configuration files are newer and often less monitored.
Attackers noticed the gap.
Why This Technique Is Hard to Detect
The June 5 attack avoided some traditional detection paths.
Downloading or cloning a repository may not trigger an alert because repositories are normally considered trusted development assets.
Opening the repository in an IDE or AI coding agent is also normal developer behavior.
But if the repository contains malicious configuration files for tools like Claude Code, Gemini CLI, Cursor, or VS Code, the attacker can execute code through a trusted workflow that many scanners do not yet inspect deeply.
This shifts the attack point from package installation to developer environment activation.
The threat is no longer only “what dependency did you install?” It is also “what configuration did your editor or AI coding tool automatically trust?”
Why the Exposure Window Matters
GitHub’s automated defenses reportedly flagged and removed the affected repositories within hours.
That may sound fast, but for a self-spreading worm, even a short exposure window can be enough.
If a developer cloned an affected repository and opened it with one of the targeted tools, credentials could be harvested almost immediately.
Those stolen credentials could then be used to push more malicious commits, publish poisoned packages, or compromise more accounts.
This creates a compounding blast radius.
In worm-like supply chain attacks, the question is not only how long the malware was present. It is who interacted with it during that window and what access their credentials provided.
One high-value developer account may be enough to seed the next wave.
CI/CD Pipelines Are Highly Sensitive Dependencies
The incident also shows how organizations rely on external CI/CD building blocks.
GitHub Actions are often referenced directly in workflows, sometimes by tags such as @v1.
If the action is compromised, disabled, removed, or replaced, downstream pipelines may fail or become unsafe.
Organizations should treat CI/CD dependencies as production dependencies.
This includes:
- GitHub Actions
- reusable workflows
- third-party build tools
- deployment actions
- package publishing automation
- AI coding agents
- code-generation tools
- IDE extensions
- repository configuration files
A compromise in any of these layers can affect build integrity.
What Organizations Should Do If They Cloned Affected Repositories
StepSecurity urged organizations that cloned affected Microsoft repositories after June 2 and opened them with targeted AI coding tools or IDEs to assume compromise.
Recommended response steps include:
- rotate all developer credentials
- rotate GitHub tokens
- rotate npm and PyPI publishing tokens
- rotate cloud credentials
- review CI/CD secrets
- audit GitHub Actions workflows
- inspect local developer machines
- review packages published after exposure
- check for suspicious commits
- inspect logs for outbound traffic to attacker infrastructure
- audit use of Claude Code, Gemini CLI, Cursor, and VS Code configuration files
- check for unexpected tool configuration changes
If a developer system interacted with the malicious configuration, credential theft should be assumed until disproven.
Preventing Similar Attacks
Organizations should update supply chain defenses to cover AI coding tools and repository-level configuration.
Recommended controls include:
- inspect cloned repositories for suspicious AI agent configuration files
- review VS Code workspace settings before opening unknown repositories
- disable automatic execution features where possible
- restrict AI coding tools from running arbitrary commands automatically
- monitor outbound network access from developer workstations
- restrict outbound access from CI/CD runners
- require branch protection rules for all commits
- require review for workflow and configuration file changes
- pin GitHub Actions to trusted commit SHAs where possible
- limit repository write permissions
- use short-lived and scoped credentials
- rotate tokens after any suspected compromise
- monitor for unexpected package publishing
- audit contributors and active tokens regularly
The key is to treat AI coding environments as part of the attack surface.
Why Branch Protection Matters
Branch protection rules can reduce the chance that malicious commits land unnoticed.
Organizations should require:
- pull request reviews
- status checks
- signed commits where appropriate
- restricted workflow file changes
- approval for GitHub Actions changes
- protected release branches
- limited direct push access
- mandatory review for configuration files
Special attention should be given to files that control build behavior, IDE behavior, AI coding agents, or package publication.
Attackers increasingly target files that look like configuration rather than obvious source code.
Outbound Network Controls Are Critical
Many supply chain attacks rely on exfiltrating stolen credentials to command-and-control infrastructure.
Organizations should restrict outbound access from CI/CD runners and developer environments where possible.
Useful controls include:
- egress allowlisting for CI/CD runners
- blocking known malicious C2 domains
- monitoring unusual DNS lookups
- alerting on unexpected outbound HTTP requests
- restricting access to paste sites and anonymous file hosts
- inspecting traffic from build environments
- separating build systems from developer browsing environments
CI/CD runners often hold sensitive secrets. They should not have unrestricted outbound internet access unless there is a clear need.
Lessons From the Incident
The Miasma incident highlights several lessons.
First, software supply chain worms can spread quickly through trusted developer infrastructure.
Second, widely used GitHub Actions can become single points of failure for global CI/CD pipelines.
Third, credential rotation after a compromise must be complete and verified.
Fourth, AI coding tools and IDE configuration files are now active attack surfaces.
Fifth, short exposure windows can still create serious risk when self-propagating malware is involved.
Defenders must expand their view of software supply chain security beyond package registries.
Final Thoughts
The Miasma worm’s impact on Microsoft GitHub repositories is a warning about the next phase of software supply chain attacks.
The disruption of 73 Microsoft repositories was serious on its own, but the deeper issue is the technique: attackers are shifting from poisoned package installs to trusted developer environments and AI coding tool configurations.
That makes detection harder and expands the attack surface.
Organizations should review any repositories cloned during the exposure window, rotate credentials where needed, inspect AI agent configuration files, and harden CI/CD workflows.
The lesson is clear: in modern software supply chains, trust must be verified at every layer — including the tools developers use to write code.
