GitHub disabled 73 Microsoft-owned repositories on June 5, 2026, after the Miasma worm reportedly reached Azure’s durabletask project through a compromised contributor account and planted credential-stealing payloads designed to run inside developer tools and AI coding agents. The incident matters less because Microsoft was embarrassed and more because the trigger moved closer to the developer’s hands. A poisoned package used to become dangerous when it was installed; Miasma made the mere act of opening a cloned repository in the wrong tool part of the attack path. That is a nasty evolution for Windows developers, Azure customers, and every administrator now being asked to trust AI-assisted development workflows at enterprise speed.
For years, the software supply chain story had a familiar rhythm. Attackers poisoned a package, waited for a build pipeline or developer machine to run an install script, then harvested secrets or shipped backdoored code downstream. Defenders responded by scanning package registries, pinning versions, watching lockfiles, and treating dependency installation as the danger zone.
Miasma shifts that boundary. According to multiple security reports, the worm did not rely on changing Microsoft’s ordinary source code in a way that would necessarily stand out during review. Instead, it added tool-facing files that could trigger execution when a developer opened the repository in environments such as Claude Code, Cursor, Gemini CLI, or VS Code.
That distinction is not academic. Modern coding agents are built to read, reason, scaffold, execute, and “help” inside a workspace. The more useful they become, the more they blur the line between a passive editor and an active automation surface.
This is the bargain developers have been making, often without calling it a bargain. AI tooling saves time by absorbing context and taking action. Miasma’s lesson is that context itself can now be hostile.
The spectacle of Microsoft-owned repositories being taken offline will naturally dominate headlines. But the more important target was not Microsoft’s public image. It was the trust chain that makes open source development function at scale.
Developers clone Microsoft repositories because they assume the namespace, stars, history, and maintainer graph mean something. Enterprises build pipelines around GitHub Actions and SDKs because they assume reputable upstream projects are safer than random third-party code. AI coding agents compound that assumption by eagerly ingesting project files as working context.
Miasma weaponized that entire social contract. A repository does not need to ship a malicious release if it can compromise the person who opens it, steal that person’s tokens, and then use those tokens to reach the next writable repository.
That is why this campaign feels different from the usual dependency scare. It is not merely a bad artifact sitting in a registry. It is a contagion model built around developer identity.
Security researchers have connected the June incident to earlier activity involving Microsoft’s durabletask Python packages on PyPI in May. That earlier compromise reportedly involved malicious package versions and stolen publishing or contributor access. The June wave suggests that whatever credentials or access patterns were involved, the campaign had not simply ended with a package takedown.
That is a recurring failure mode in supply chain incidents. Organizations remove the visible poisoned object, then underestimate how much identity cleanup remains. Rotating tokens, invalidating sessions, auditing GitHub Actions secrets, reviewing branch permissions, and checking dormant branches are tedious tasks that do not generate triumphant incident-response blog posts.
Attackers know this. They do not need every stolen key to keep working. They need one overlooked credential with the right write access at the right time.
Miasma’s reported use of a backdated commit in a dormant branch adds another layer of cynicism. The attacker was not only trying to spread; the attacker was trying to blend into the sediment of a long-lived repository. In sprawling open source projects, old branches are often archaeological layers that few people inspect unless something breaks.
The reported Miasma payload was designed to fire through configuration and instruction files rather than obvious application code changes. That design fits the new development environment, where files are not just files. A workspace may contain editor settings, agent rules, model instructions, task definitions, hooks, scripts, and metadata that tell tools what to do before the developer has meaningfully reviewed anything.
Traditional advice tells developers not to run random scripts. But an AI coding workflow can turn “open this project and inspect it” into a semi-automated sequence of reads, suggestions, shell commands, and dependency operations. The user may think they are browsing. The tool may be acting.
This is the uncomfortable part for AI vendors. If a product encourages developers to trust the workspace as a source of instructions, then malicious workspaces become prompt-injection containers with filesystem privileges. If a product automatically executes helper code or makes execution easy through trusted project conventions, then it inherits the security burden of an automation platform.
The distinction between editor, agent, and build tool is collapsing. Attackers are not waiting for the industry to finish naming the new category.
A stolen token is more flexible than a backdoor. It can publish packages, push commits, read private repositories, create workflow runs, enumerate cloud resources, and impersonate a legitimate maintainer. It can also allow the attacker to choose timing and delivery mechanisms after the original incident has faded from attention.
This is why “we removed the malicious commit” is never enough. If a developer opened an affected repository and the payload executed, the right response is not simply deleting the clone. It is treating the machine and every accessible credential as suspect.
For Windows developers, that means checking more than the obvious environment variables. WSL home directories, PowerShell profiles, Azure CLI tokens, GitHub CLI authentication, npm and PyPI credentials, SSH keys, browser-backed secrets, and synced password managers all belong in the incident-response picture. The workstation is not a peripheral asset in this story. It is the battlefield.
Enterprises should also resist the urge to narrow the response only to Microsoft repositories. Miasma’s reported dead-drop infrastructure and repeated pivots across npm, PyPI, GitHub repositories, and tool-specific execution paths suggest a campaign optimized for movement, not a one-off compromise of a famous vendor.
This is the platform owner’s dilemma. Leaving compromised repositories online risks further infection. Taking them offline breaks legitimate workflows, sometimes in production-adjacent environments. The more central a repository is, the less graceful the emergency brake becomes.
Microsoft reportedly said it temporarily removed some repositories while investigating potentially malicious content, restored some after review, and notified a small number of customers who may have pulled affected content. That is the carefully worded corporate version of incident response. It may be accurate, but it does not answer the question most developers care about: did my machine run the payload?
That gap is where trust erodes. Terms-of-service takedown language may be legally convenient, but it is operationally weak when credential theft is plausible. Developers and administrators need dates, commit hashes, affected repository lists, indicators of compromise, and explicit guidance on what actions should trigger credential rotation.
The industry has learned this lesson repeatedly with package registry compromises. It now has to relearn it for repositories and AI workspaces.
That means defenders need to inspect files that historically looked like developer convenience rather than production risk. Editor settings, agent rules, setup scripts, GitHub workflow fragments, prompt-like instruction files, and language-tool configuration can all become part of the threat model. A malicious change does not have to touch the application’s main code path to matter.
For Windows shops, the risk is amplified by the common sprawl of development environments. A single engineer may use VS Code on Windows, WSL for Linux tooling, Docker Desktop for containers, GitHub CLI for repository access, Azure CLI for cloud work, Node and Python package managers, and an AI agent that can see much of it. That stack is productive because it is interconnected. It is risky for the same reason.
Security teams often have better visibility into CI than into local development machines. Miasma attacks that blind spot. If the compromise happens before code reaches CI, and if the payload steals credentials rather than modifying the application, your pipeline may faithfully build clean code while the attacker walks away with the keys.
The right response is not to ban AI coding tools outright. That would be unrealistic in many organizations and performative in most. The right response is to stop pretending they are harmless text editors.
That means agent vendors need safer defaults. Opening a repository should not silently execute project-supplied instructions with access to shell, network, secrets, and credential stores. Workspace trust prompts should be specific enough to tell users what capability is being granted, not vague enough to become another “click OK to continue” ritual.
It also means enterprises need policy controls that match how developers actually work. If an AI coding agent can run commands, it belongs in endpoint detection policy. If it can read secrets, it belongs in secret-management policy. If it can push commits or open pull requests, it belongs in identity governance.
The uncomfortable truth is that many organizations have deployed AI coding tools faster than they have classified them. Some treat them like productivity plug-ins. Others treat them like SaaS applications. Miasma argues they are closer to privileged automation clients embedded in the developer workstation.
That does not make them unusable. It makes them governable.
Repository owners should treat configuration files as executable risk, not administrative clutter. Any change that adds agent instructions, setup scripts, workflow files, shell hooks, package manager lifecycle hooks, or editor automation deserves scrutiny. That is especially true in projects with broad downstream use.
Branch protection also needs to account for dormant branches. An attacker who can push to an old branch in a respected repository can create confusion, stage payloads, and exploit users who clone or inspect branches casually. The historical record of a repository is part of its trust surface.
For administrators, the practical test is simple: if a developer cloned an affected repository on or after the relevant compromise window, opened it in an AI coding tool or IDE, and had cloud or GitHub credentials available on the same machine, assume credential exposure until proven otherwise. That is stricter than many teams would like. It is also more realistic than hoping the payload did not run.
When GitHub disables Microsoft repositories, the ecosystem needs transparent, actionable communication. Which repositories were affected? Which commits or branches contained malicious files? Which tools could trigger execution? Which credentials should users rotate? Which artifacts are safe now? Ambiguity forces each organization to invent its own incident model, and many will choose the least disruptive one.
The company’s reported restoration of some repositories after review is welcome, but restoration is not the same as remediation for those who cloned during the window of risk. A cleaned upstream repository cannot unsteal a token from a developer workstation. That is the part many non-security stakeholders miss.
Microsoft also has to contend with the optics of repeated durabletask-related incidents. Even if the technical chain is more nuanced than “Microsoft failed twice,” the pattern will be read that way by customers unless the company shows its work. In supply chain security, confidence is built through specificity.
The stakes are larger than this one worm. Microsoft has spent years positioning GitHub, Azure, VS Code, Copilot, and cloud-native developer workflows as a unified productivity fabric. Miasma shows that attackers see the same fabric as a unified credential-harvesting surface.
Here is the compressed version for Windows developers, Azure administrators, and security teams trying to turn this into action rather than anxiety:
That is why this incident should not be filed away as another GitHub cleanup story. It is a preview of how supply chain attacks adapt when developers hand more agency to their tools. The malware did not need to persuade users to run a suspicious binary. It needed the modern development environment to behave as designed.
The future of coding will almost certainly include more agents, more automation, and more context-aware tooling. The security model has to catch up with that reality, not wish it away. Miasma’s real message is that trust in open source now extends beyond packages and pipelines into the moment a workspace is opened, parsed, and acted upon; the next defensible developer platform will be the one that treats that moment as a security boundary rather than a convenience feature.
The Supply Chain Attack Has Moved From Install Time to Open Time
For years, the software supply chain story had a familiar rhythm. Attackers poisoned a package, waited for a build pipeline or developer machine to run an install script, then harvested secrets or shipped backdoored code downstream. Defenders responded by scanning package registries, pinning versions, watching lockfiles, and treating dependency installation as the danger zone.Miasma shifts that boundary. According to multiple security reports, the worm did not rely on changing Microsoft’s ordinary source code in a way that would necessarily stand out during review. Instead, it added tool-facing files that could trigger execution when a developer opened the repository in environments such as Claude Code, Cursor, Gemini CLI, or VS Code.
That distinction is not academic. Modern coding agents are built to read, reason, scaffold, execute, and “help” inside a workspace. The more useful they become, the more they blur the line between a passive editor and an active automation surface.
This is the bargain developers have been making, often without calling it a bargain. AI tooling saves time by absorbing context and taking action. Miasma’s lesson is that context itself can now be hostile.
Microsoft Was the Victim, But the Target Was Developer Trust
The reported Microsoft impact was unusually visible: 73 repositories across Azure, Azure-Samples, Microsoft, and MicrosoftDocs were disabled in a rapid automated GitHub response. Affected projects reportedly included Azure Functions components, Durable Task repositories across multiple languages, AI samples such as azure-search-openai-demo, and other cloud-adjacent developer assets.The spectacle of Microsoft-owned repositories being taken offline will naturally dominate headlines. But the more important target was not Microsoft’s public image. It was the trust chain that makes open source development function at scale.
Developers clone Microsoft repositories because they assume the namespace, stars, history, and maintainer graph mean something. Enterprises build pipelines around GitHub Actions and SDKs because they assume reputable upstream projects are safer than random third-party code. AI coding agents compound that assumption by eagerly ingesting project files as working context.
Miasma weaponized that entire social contract. A repository does not need to ship a malicious release if it can compromise the person who opens it, steal that person’s tokens, and then use those tokens to reach the next writable repository.
That is why this campaign feels different from the usual dependency scare. It is not merely a bad artifact sitting in a registry. It is a contagion model built around developer identity.
Durable Task Became the Doorway No One Wanted to See
The reported entry point, Azure/durabletask, is a particularly uncomfortable one for Microsoft’s ecosystem. Durable Task is not a toy project or an abandoned sample; it sits near the orchestration layer for cloud workflows and has sibling implementations that matter to real applications. When a project like that becomes a staging point, the blast radius is psychological as well as technical.Security researchers have connected the June incident to earlier activity involving Microsoft’s durabletask Python packages on PyPI in May. That earlier compromise reportedly involved malicious package versions and stolen publishing or contributor access. The June wave suggests that whatever credentials or access patterns were involved, the campaign had not simply ended with a package takedown.
That is a recurring failure mode in supply chain incidents. Organizations remove the visible poisoned object, then underestimate how much identity cleanup remains. Rotating tokens, invalidating sessions, auditing GitHub Actions secrets, reviewing branch permissions, and checking dormant branches are tedious tasks that do not generate triumphant incident-response blog posts.
Attackers know this. They do not need every stolen key to keep working. They need one overlooked credential with the right write access at the right time.
Miasma’s reported use of a backdated commit in a dormant branch adds another layer of cynicism. The attacker was not only trying to spread; the attacker was trying to blend into the sediment of a long-lived repository. In sprawling open source projects, old branches are often archaeological layers that few people inspect unless something breaks.
The AI Agent Is Now Part of the Attack Surface
The phrase “AI coding agent” still sounds futuristic to some enterprise security teams, but in practice these tools are already sitting inside developer workstations with file access, terminal access, repository access, and sometimes cloud credentials nearby. That is exactly why they are useful. It is also exactly why they are dangerous.The reported Miasma payload was designed to fire through configuration and instruction files rather than obvious application code changes. That design fits the new development environment, where files are not just files. A workspace may contain editor settings, agent rules, model instructions, task definitions, hooks, scripts, and metadata that tell tools what to do before the developer has meaningfully reviewed anything.
Traditional advice tells developers not to run random scripts. But an AI coding workflow can turn “open this project and inspect it” into a semi-automated sequence of reads, suggestions, shell commands, and dependency operations. The user may think they are browsing. The tool may be acting.
This is the uncomfortable part for AI vendors. If a product encourages developers to trust the workspace as a source of instructions, then malicious workspaces become prompt-injection containers with filesystem privileges. If a product automatically executes helper code or makes execution easy through trusted project conventions, then it inherits the security burden of an automation platform.
The distinction between editor, agent, and build tool is collapsing. Attackers are not waiting for the industry to finish naming the new category.
Credential Theft Remains the Worm’s Real Payload
Miasma’s apparent aim was not subtle sabotage of Microsoft source code. The payload reportedly searched for cloud and developer credentials, including AWS, Google Cloud, Azure, GitHub Actions secrets, and local password-store material from tools such as 1Password, gopass, and pass. That is the modern supply chain attacker’s preferred loot because credentials turn one compromise into many.A stolen token is more flexible than a backdoor. It can publish packages, push commits, read private repositories, create workflow runs, enumerate cloud resources, and impersonate a legitimate maintainer. It can also allow the attacker to choose timing and delivery mechanisms after the original incident has faded from attention.
This is why “we removed the malicious commit” is never enough. If a developer opened an affected repository and the payload executed, the right response is not simply deleting the clone. It is treating the machine and every accessible credential as suspect.
For Windows developers, that means checking more than the obvious environment variables. WSL home directories, PowerShell profiles, Azure CLI tokens, GitHub CLI authentication, npm and PyPI credentials, SSH keys, browser-backed secrets, and synced password managers all belong in the incident-response picture. The workstation is not a peripheral asset in this story. It is the battlefield.
Enterprises should also resist the urge to narrow the response only to Microsoft repositories. Miasma’s reported dead-drop infrastructure and repeated pivots across npm, PyPI, GitHub repositories, and tool-specific execution paths suggest a campaign optimized for movement, not a one-off compromise of a famous vendor.
GitHub’s Fast Takedown Was Necessary, But It Was Not a Cure
GitHub’s automated disablement of the affected Microsoft repositories appears to have been fast, reportedly spanning just 105 seconds across two waves. That speed is impressive and likely prevented additional clones, forks, and automated pulls. It also created immediate operational pain for anyone depending on those repositories or actions.This is the platform owner’s dilemma. Leaving compromised repositories online risks further infection. Taking them offline breaks legitimate workflows, sometimes in production-adjacent environments. The more central a repository is, the less graceful the emergency brake becomes.
Microsoft reportedly said it temporarily removed some repositories while investigating potentially malicious content, restored some after review, and notified a small number of customers who may have pulled affected content. That is the carefully worded corporate version of incident response. It may be accurate, but it does not answer the question most developers care about: did my machine run the payload?
That gap is where trust erodes. Terms-of-service takedown language may be legally convenient, but it is operationally weak when credential theft is plausible. Developers and administrators need dates, commit hashes, affected repository lists, indicators of compromise, and explicit guidance on what actions should trigger credential rotation.
The industry has learned this lesson repeatedly with package registry compromises. It now has to relearn it for repositories and AI workspaces.
The Old Defenses Are Pointing at the Wrong Door
Many software supply chain defenses assume the dangerous moment is a package install, a build step, or a release artifact. That assumption still matters, but Miasma shows it is incomplete. The repository itself has become an execution environment.That means defenders need to inspect files that historically looked like developer convenience rather than production risk. Editor settings, agent rules, setup scripts, GitHub workflow fragments, prompt-like instruction files, and language-tool configuration can all become part of the threat model. A malicious change does not have to touch the application’s main code path to matter.
For Windows shops, the risk is amplified by the common sprawl of development environments. A single engineer may use VS Code on Windows, WSL for Linux tooling, Docker Desktop for containers, GitHub CLI for repository access, Azure CLI for cloud work, Node and Python package managers, and an AI agent that can see much of it. That stack is productive because it is interconnected. It is risky for the same reason.
Security teams often have better visibility into CI than into local development machines. Miasma attacks that blind spot. If the compromise happens before code reaches CI, and if the payload steals credentials rather than modifying the application, your pipeline may faithfully build clean code while the attacker walks away with the keys.
The right response is not to ban AI coding tools outright. That would be unrealistic in many organizations and performative in most. The right response is to stop pretending they are harmless text editors.
AI Coding Tools Need a Seat in Zero Trust
The enterprise security phrase zero trust has been stretched almost beyond usefulness, but Miasma gives it a concrete new application. A coding agent should not inherit unlimited trust simply because the developer launched it. It should earn permissions in small, auditable steps.That means agent vendors need safer defaults. Opening a repository should not silently execute project-supplied instructions with access to shell, network, secrets, and credential stores. Workspace trust prompts should be specific enough to tell users what capability is being granted, not vague enough to become another “click OK to continue” ritual.
It also means enterprises need policy controls that match how developers actually work. If an AI coding agent can run commands, it belongs in endpoint detection policy. If it can read secrets, it belongs in secret-management policy. If it can push commits or open pull requests, it belongs in identity governance.
The uncomfortable truth is that many organizations have deployed AI coding tools faster than they have classified them. Some treat them like productivity plug-ins. Others treat them like SaaS applications. Miasma argues they are closer to privileged automation clients embedded in the developer workstation.
That does not make them unusable. It makes them governable.
Repository Hygiene Is Now Incident Response
The reported Miasma campaign also exposes a quieter problem: many repositories are too permissive, too old, and too hard to reason about quickly. Dormant branches, broad contributor access, long-lived tokens, and inherited automation secrets make excellent hiding places. Attackers do not need to defeat your entire security program if they can find one neglected path into a trusted namespace.Repository owners should treat configuration files as executable risk, not administrative clutter. Any change that adds agent instructions, setup scripts, workflow files, shell hooks, package manager lifecycle hooks, or editor automation deserves scrutiny. That is especially true in projects with broad downstream use.
Branch protection also needs to account for dormant branches. An attacker who can push to an old branch in a respected repository can create confusion, stage payloads, and exploit users who clone or inspect branches casually. The historical record of a repository is part of its trust surface.
For administrators, the practical test is simple: if a developer cloned an affected repository on or after the relevant compromise window, opened it in an AI coding tool or IDE, and had cloud or GitHub credentials available on the same machine, assume credential exposure until proven otherwise. That is stricter than many teams would like. It is also more realistic than hoping the payload did not run.
Microsoft’s Ecosystem Has a Signaling Problem
Microsoft is both a victim and an infrastructure steward here. It owns GitHub, operates Azure, publishes the affected repositories, and sells the developer tools many WindowsForum readers use daily. That concentration makes its response more important than an ordinary vendor advisory.When GitHub disables Microsoft repositories, the ecosystem needs transparent, actionable communication. Which repositories were affected? Which commits or branches contained malicious files? Which tools could trigger execution? Which credentials should users rotate? Which artifacts are safe now? Ambiguity forces each organization to invent its own incident model, and many will choose the least disruptive one.
The company’s reported restoration of some repositories after review is welcome, but restoration is not the same as remediation for those who cloned during the window of risk. A cleaned upstream repository cannot unsteal a token from a developer workstation. That is the part many non-security stakeholders miss.
Microsoft also has to contend with the optics of repeated durabletask-related incidents. Even if the technical chain is more nuanced than “Microsoft failed twice,” the pattern will be read that way by customers unless the company shows its work. In supply chain security, confidence is built through specificity.
The stakes are larger than this one worm. Microsoft has spent years positioning GitHub, Azure, VS Code, Copilot, and cloud-native developer workflows as a unified productivity fabric. Miasma shows that attackers see the same fabric as a unified credential-harvesting surface.
The Practical Lessons Are Harsher Than the Headline
The headline version of this incident is simple: a worm hit Microsoft repositories and targeted AI coding agents. The operational version is more demanding. It asks teams to revisit what they trust when a developer opens a folder.Here is the compressed version for Windows developers, Azure administrators, and security teams trying to turn this into action rather than anxiety:
- Treat any machine that opened an affected repository in an AI coding agent or IDE during the compromise window as potentially exposed.
- Rotate GitHub, Azure, AWS, Google Cloud, package registry, SSH, and local developer tokens that were accessible from those systems.
- Audit repositories for unexpected agent rules, editor configuration, setup scripts, workflow changes, and dormant-branch commits, not just application source changes.
- Restrict AI coding agents so they cannot automatically execute workspace-supplied instructions with shell, network, or secret access.
- Pin GitHub Actions and critical dependencies to immutable references where practical, and monitor for upstream repository disappearance or emergency disablement.
- Make developer workstations part of supply chain incident response, because credential theft often happens before CI/CD systems see anything suspicious.
The Next Worm Will Not Need Microsoft to Make This Work
Miasma is alarming because it reached Microsoft, but its technique does not depend on Microsoft. Any trusted repository with enough developer attention can become bait. Any contributor account with write access can become a distribution channel. Any AI coding agent that treats project files as instructions can become the trigger.That is why this incident should not be filed away as another GitHub cleanup story. It is a preview of how supply chain attacks adapt when developers hand more agency to their tools. The malware did not need to persuade users to run a suspicious binary. It needed the modern development environment to behave as designed.
The future of coding will almost certainly include more agents, more automation, and more context-aware tooling. The security model has to catch up with that reality, not wish it away. Miasma’s real message is that trust in open source now extends beyond packages and pipelines into the moment a workspace is opened, parsed, and acted upon; the next defensible developer platform will be the one that treats that moment as a security boundary rather than a convenience feature.
References
- Primary source: londoninsider.co.uk
Published: 2026-06-10T23:01:12.564809
- Related coverage: techradar.com
- Related coverage: data-today.net
Miasma worm turns AI coding agents into repo traps
Miasma worm is a credential stealer that hit 73 Microsoft GitHub repos. Treat agent-opened clones as compromised, not suspicious.
data-today.net
- Related coverage: redmondmag.com
Supply Chain Attack Hits Microsoft GitHub Repos, AI Coding Tools -- Redmondmag.com
GitHub disabled 73 Microsoft repositories on June 5 after a malicious commit landed in an Azure project, in what researchers described as a supply chain attack aimed at developer workstations and AI coding environments.
redmondmag.com
- Related coverage: byteiota.com
- Related coverage: awesomeagents.ai
Miasma Worm Compromises 73 Microsoft GitHub Repos
Miasma worm planted config files that auto-execute credential theft when developers open Microsoft Azure repos in Claude Code, Gemini CLI, Cursor, or VS Code.
awesomeagents.ai
- Related coverage: gate.com
Buy/Sell Bitcoin, Ethereum and 4,700+ Altcoins | Cryptocurrency Exchange | Gate.com
Gate - Leading cryptocurrency exchange with over 4,700 cryptocurrencies & stablecoins such as Bitcoin ✓ Ethereum ✓ Dogecoin ✓ Start trading crypto with Gate.com now!www.gate.com - Related coverage: thenextweb.com
Self-replicating Miasma worm hits 73 Microsoft GitHub repositories in supply chain attack
GitHub disabled 73 Microsoft repos after the Miasma worm exploited previously compromised credentials to plant malware targeting AI coding agents.
thenextweb.com
- Related coverage: cybernews.com
- Related coverage: windowsforum.com
GitHub disables 73 Microsoft Azure repos after “Miasma” editor/AI workspace attack
On June 5, 2026, GitHub disabled 73 repositories across Microsoft’s Azure, Microsoft, Azure-Samples, and MicrosoftDocs organizations after a malicious commit was pushed to Azure/durabletask through a reportedly compromised contributor account. The immediate blast radius was not Windows Update or...
windowsforum.com
- Related coverage: darkreading.com
- Related coverage: labs.cloudsecurityalliance.org
- Related coverage: zeronoise.ai
- Related coverage: computing.co.uk
Microsoft’s GitHub repositories taken offline amid Miasma supply chain attack
Dozens of Microsoft-owned software repositories have been taken offline following a major cyberattack linked to the rapidly spreading Miasma malware campaign.
www.computing.co.uk
- Related coverage: devops.com
- Related coverage: thehackernews.com
Microsoft Restores Some GitHub Repos, Keeps Others Offline as Miasma Probe Continues
Microsoft confirms it temporarily removed GitHub repos after Miasma worm compromised 73 of its open-source projects to inject an information stealer.
thehackernews.com
- Related coverage: qore.com
GitHub deshabilita 73 repositorios de Microsoft por Miasma
GitHub deshabilitó de emergencia 73 repositorios de Microsoft tras detectar el ataque del gusano Miasma.
www.qore.com
- Related coverage: perplexityaimagazine.com
Miasma Worm GitHub Attack 2026: 73 Microsoft Repos
Miasma worm GitHub attack 2026 disables 73 Microsoft repos by targeting Claude Code and VS Code developer environments worldwide.
perplexityaimagazine.com
- Related coverage: rescana.com
Miasma Worm Supply Chain Attack: 73 Microsoft GitHub Repositories Compromised via AI Coding Tools
Executive SummaryOn June 5, 2026, the Miasma worm, a self-replicating supply chain malware, compromised 73 Microsoft GitHub repositories across four major organizations: Azure, Azure-Samples, Microsof
www.rescana.com
- Related coverage: aiweekly.co
- Related coverage: stepsecurity.io
Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents - StepSecurity
On June 5, 2026, the Miasma worm campaign reached Microsoft's Azure GitHub organizations. GitHub disabled 73 repositories across four Microsoft GitHub organizations after a malicious commit was pushed to the Azure/durabletask repository using a previously compromised contributor account. The...
www.stepsecurity.io
- Related coverage: unaaldia.hispasec.com
El gusano Miasma compromete 73 repositorios de Microsoft en GitHub y fuerza su desactivación
La campaña Miasma ha comprometido 73 repositorios públicos de Microsoft en GitHub, que la plataforma terminó deshabilitando. El ataque no se apoyó en un fallo de GitHub o npm, sino en credenciales …
unaaldia.hispasec.com
