GitHub disables 73 Microsoft repos in 105 seconds after Miasma worm CI/CD break

GitHub disabled 73 Microsoft repositories in just 105 seconds after it detected signs of the Miasma worm infecting projects on Friday, June 5. The speed mattered. Users hit the affected repo URLs and were met with the same message indicating the repos were disabled due to terms of service violations, while teams scrambled because their development workflows started failing immediately.

The immediate operational blast radius showed up as broken CI/CD pipelines. Several developers reported that their pipelines stopped working after the takedowns began, according to a support thread. A moderator at the time suggested this was an internal management issue, but StepSecurity’s co-founder and CTO Ashish Kurmi described the technical trigger: the attack kicked off when a compromised contributor account pushed a malicious commit to Azure/durabletask. That commit dropped configuration files designed to trigger remote code execution on machines when a developer opened the repo in an IDE or AI coding tool, including Claude Code, Gemini CLI, and Cursor.

If you are an executive, the scary part is not just that code got malicious. It is that the payload path was engineered around the way software teams actually work day to day. Opening a repository in an IDE or AI coding tool is routine. In this case, it could lead to remote code execution on developers’ machines, which then can turn “build pipeline automation” from a productivity asset into a credential and configuration collection system.

StepSecurity’s analysis points to what specifically broke: the repo Azure/functions-action. Kurmi wrote that this repo was “the repo that most immediately caused issues,” used to deploy code to Azure. With Azure/functions-action@v1 taken down, every workflow referencing Azure/functions-action@v1 stopped resolving. That kind of dependency failure is second-order damage even after the malware is removed, because pipelines, approvals, and releases are often built on assumptions that upstream action tags will continue to exist and validate.

Zoom out, and the durabletask details hint at why this incident looks like more than a one-off. StepSecurity noted that Microsoft’s durabletask PyPI package was a previous target of the Miasma worm on May 19. Within a 35-minute window, three versions of the package were uploaded to PyPi, planting infostealers on developers’ machines. Those infostealers focused on sniffing out cloud secrets and developer tool configurations on Linux systems. Kurmi said the retargeting of durabletask suggests tokens associated with the compromised developer account were not fully rotated. In other words: an attacker likely kept enough access to repeat the playbook. Alternatively, Kurmi said, the contributor could have been re-compromised through the worm’s own propagation loop, or a different contributor’s token could have been used while the attacker altered metadata to make it look like a repeated attack.

The broader worm story also matters for governance and board-level risk. Snyk described Miasma as a descendant of the Mini Shai Hulud worm, referencing a larger pattern of open-source abuse. Mini Shai Hulud previously ravaged open source packages on the npm registry, including Red Hat’s, earlier this month. Cybercrime group TeamPCP claimed responsibility for developing Mini Shai Hulud, which is named after an earlier worm of the same name, sans “mini.” However, because TeamPCP open-sourced Mini Shai Hulud, it is hard to determine whether TeamPCP also authored Miasma or whether someone else took over the follow-up project.

StepSecurity also reported that two days before the Microsoft GitHub incident, the same worm was making a nuisance of itself at npm, compromising more than 50 packages. That included a Vapi.ai SDK with more than 408,000 monthly downloads. In plain terms: while Microsoft and GitHub were dealing with takedowns, the worm activity was not localized to a single ecosystem. For executives, this is how open-source supply chain risk becomes a multi-surface problem: your stack might integrate npm packages, PyPI distributions, and GitHub actions, and the attacker only needs one weak link in any of those to start the chain reaction.

GitHub disabled the infected repositories in under two minutes, in two separate waves, and stepped in a few hours after the repos were infected by the malicious commit. The Register asked Microsoft for comment, but it did not immediately respond. For companies that run CI/CD and rely on third-party actions, the strategic stakes are clear: an attacker does not need to breach your internal systems first. If they can get into a widely referenced repo or package and trigger execution through normal developer behavior, your operational continuity, credential hygiene, and release schedules can all be undermined quickly enough to become an existential weekend problem.