On June 5, 2026, GitHub disabled 73 Microsoft-owned repositories across Azure, Azure-Samples, microsoft, and MicrosoftDocs after researchers said the Miasma supply-chain worm used a compromised contributor path to plant malicious developer-tool configuration files in Microsoft’s open-source estate. The incident was not just another poisoned-package scare. It was a reminder that modern software delivery now depends on a sprawling chain of tags, actions, editors, agents, tokens, and trust assumptions that can fail in ways no service status page is built to explain. For WindowsForum readers, the lesson is blunt: the build pipeline has become part of the attack surface, and AI coding tools have become part of the blast radius.
The most visible damage was not a Windows desktop compromise or an Azure platform outage in the classic sense. It was a dependency-resolution failure: workflows that referenced Microsoft-hosted GitHub Actions suddenly could not find what they expected to find. That is a quieter kind of outage, but for teams pushing production code through CI/CD, it is just as real.
The affected set reportedly included Azure Functions and Durable Task repositories, with Azure/functions-action drawing the most attention because it is not merely a library people browse. It is an action embedded in deployment workflows, the kind of component that sits invisibly inside a YAML file until the day it stops resolving. When GitHub disabled the repository, downstream pipelines did exactly what tightly coupled automation does: they failed.
That distinction matters. A compromised repository can be a security event, but a disabled repository can become an availability event for everyone who treats that repository as infrastructure. The modern open-source cloud stack has blurred the line between source code, release artifact, documentation, deployment tool, and operational dependency.
Microsoft later said the repositories had been restored and that affected customers were notified while investigation work continued. That is the correct procedural ending to the first phase of the incident, but it does not close the larger story. The larger story is that a repository platform’s safety intervention became, by design, a global CI/CD breaker for organizations that had delegated deployment reliability to a live upstream reference.
The June 5 incident was more unsettling because the attackers reportedly did not need to alter normal source code paths. Researchers said malicious configuration files were planted for tools including Claude Code, Gemini CLI, Cursor, and Visual Studio Code, all pointing toward a multi-megabyte payload. In other words, the trap was set for the developer’s workspace rather than the application runtime.
That is the shift administrators should not miss. The traditional supply-chain conversation asks whether build artifacts, package versions, and container images are authentic. Miasma forces a different question: what happens when opening the repository is itself enough to place a developer’s environment in danger?
AI coding assistants make that question more urgent because they are designed to observe, index, execute, and assist inside exactly the context attackers want to reach. The more capable the tool, the more valuable its privileges become. A coding agent that can inspect a workspace, run commands, invoke package managers, read environment context, and help with deployment is not just a productivity aid; it is a potential execution surface with developer-grade access.
The alleged reuse of a compromised contributor path is the connective tissue. If researchers are right, the same broad campaign moved from registry abuse to repository abuse, using trust relationships around Microsoft-maintained open source to find the next opening. That is a familiar escalation pattern in supply-chain attacks: compromise one identity, harvest more secrets, pivot into adjacent projects, and repeat until either automation catches up or a human notices the shape of the intrusion.
The name TeamPCP has been attached to the broader campaign by researchers, and Miasma has been described as a variant or descendant in the same ecosystem as Mini Shai-Hulud. The nomenclature will matter to threat-intelligence teams, but the operational lesson is more important for most readers. The campaign’s strength is not a single exotic exploit; it is the attacker’s ability to exploit the ordinary connective tissue of software work.
That connective tissue is exactly what Microsoft, GitHub, Azure, and the open-source ecosystem have spent years optimizing. Repositories are public, actions are reusable, tokens are portable, agents are helpful, and automation is expected to move quickly. Miasma turned those virtues into propagation opportunities.
That is the operational paradox at the heart of the incident. GitHub’s intervention appears to have been a containment move, yet containment exposed how much production deployment depends on the continuous availability of upstream repositories. The platform did what a platform must do, and downstream systems paid the price.
For years, defenders have told engineering teams to pin dependencies, use lockfiles, validate signatures, and avoid floating references. GitHub Actions complicate that advice because many workflows still reference major-version tags such as
The Azure/functions-action disruption shows why that matters. If an action is treated as part of the production release path, then its availability is part of your production release risk. That is not a theoretical purity argument. It is the difference between a deploy pipeline that fails because your code is broken and one that fails because a third-party trust decision changed upstream.
That makes configuration files a more attractive target. A malicious package has to enter a dependency graph and survive scanning. A malicious workflow has to be invoked. But a malicious tool configuration can target the moment a developer opens a trusted repository. It exploits habit rather than deployment.
Visual Studio Code has long had workspace trust concepts precisely because project folders can influence editor behavior. The arrival of AI agents raises the stakes because the boundary between “read this repository” and “act on this repository” is becoming less rigid. An agent that can help fix a test, install a dependency, update a workflow, or summarize a codebase may also be in a position to expose secrets if the workspace is hostile.
The uncomfortable truth is that developers increasingly open repositories the way users once opened email attachments. They skim the project, trust the brand, and assume the toolchain will behave. Miasma is a sign that attackers understand that muscle memory very well.
That does not mean Microsoft uniquely failed in some simple way. Large open-source estates are difficult to secure because they involve many organizations, maintainers, service accounts, release systems, bots, and historical permissions. Any company with thousands of public repositories has stale access somewhere, forgotten automation somewhere else, and a steady stream of contributors who need enough permission to get work done.
But Microsoft’s role changes the expectations. Customers use Microsoft-maintained actions and SDKs because they assume the chain is safer than an unknown third-party alternative. They integrate those components into regulated environments, enterprise deployment systems, and production release paths. When that chain breaks, the damage is reputational as well as technical.
The incident also exposes a communications gap. Developers encountering disabled repositories saw GitHub terms-of-service language, broken workflows, and scattered explanations before a coherent picture emerged. That is often how supply-chain incidents unfold, but it is especially painful when the affected components sit in official cloud deployment paths. In the moment, “internal management issue” does not help a release engineer decide whether to rotate secrets, pin a commit, or halt production deployments.
A developer workstation is often a concentration point for credentials. It may hold cloud CLI sessions, GitHub tokens, package registry credentials, SSH keys, environment files, local caches, and access to internal repositories. The industry has spent years hardening production clusters while leaving developer laptops and build runners as semi-trusted convenience zones.
Build runners are even more dangerous because they are designed to assemble secrets and code at runtime. A CI job may receive deployment credentials only briefly, but briefly is enough if malicious code runs at the right moment. If a worm’s goal is credential theft and propagation, the build environment is not merely collateral. It is the target.
The presence of AI coding tools adds another identity layer. Organizations now need to know which agents are installed, what they can execute, whether they respect workspace trust boundaries, and how their configuration is reviewed. Asset inventory used to mean laptops, servers, containers, and cloud accounts. It now has to include developer agents that can act inside repositories.
If malicious behavior enters through editor configuration, agent configuration, repository hooks, or workspace metadata, a package scanner may never see the first move. If the payload is fetched only when a particular tool opens the repository, the dangerous moment may occur outside CI entirely. And if the attacker’s real goal is to steal tokens, the compromise can succeed before any suspicious dependency appears in a bill of materials.
This does not make SBOMs useless. It means they are incomplete. A software bill of materials tells you what you intended to build with. It does not automatically tell you what your developer tools executed while deciding how to build it.
Enterprise defenders should treat repositories as active content, not passive text. That means reviewing workspace settings, agent instructions, tool-specific configuration files, devcontainer definitions, pre-commit hooks, package-manager scripts, and GitHub Actions workflows with the same suspicion once reserved for executable code. The old division between “code” and “configuration” has collapsed.
But pinning is not a complete answer. If the underlying repository is disabled, the pinned commit may still become unavailable unless it is cached or mirrored. If the commit was already malicious, pinning preserves the compromise. If the danger lies in a developer opening a repository locally, the CI reference may not be the relevant path at all.
The deeper answer is layered resilience. Enterprises should mirror critical actions, maintain internal allowlists, use artifact caching, enforce token minimization, require short-lived credentials, and isolate build runners from developer workstations. They should also assume that a trusted upstream can disappear suddenly for reasons that are entirely rational from the platform’s perspective.
That last point is cultural. Many organizations treat open-source dependencies as free infrastructure without applying infrastructure-grade continuity planning. If your deployment system cannot function when a public repository is temporarily disabled, then that public repository is part of your availability model whether procurement recognizes it or not.
That convenience is the Microsoft developer story at its best. It is also why a repository-level supply-chain attack can matter even if it never touches the Windows kernel, Defender signatures, or a monthly cumulative update. The endpoint is part of the delivery chain.
Sysadmins should resist the instinct to file this under “developer problem.” Developer credentials are often privileged credentials. Developer machines often have access to production-adjacent systems. Developer tools often bypass controls that would be non-negotiable on servers because teams need flexibility to ship.
The practical Windows angle is therefore identity and execution control. Defender for Endpoint, application control, PowerShell logging, Git credential hygiene, conditional access, and privileged access management all have roles to play. But they must be applied with an understanding that the risky process may be a code editor, a terminal, a Node process spawned by an extension, or an AI agent executing inside a workspace.
Miasma did not invent that problem. It merely exploited the part of the system that had become most valuable: the automation layer around open source. The code repository is no longer just a place where humans collaborate. It is a trigger point for package publication, documentation builds, deployment actions, test infrastructure, AI agents, and cloud release machinery.
That makes Microsoft’s compromised repositories a warning about scale. The more a company standardizes on open workflows, the more any one compromised path can ripple outward. The more the ecosystem depends on canonical actions and official SDKs, the more a temporary takedown becomes a service disruption for strangers.
The answer is not to retreat from open source. It is to stop pretending that openness alone creates safety. Transparency helps after detection; it does not prevent credential theft, malicious configuration, or the misuse of legitimate maintainer access. Trust now has to be continuously verified at the level of identity, repository state, tool behavior, and build output.
Microsoft’s Open-Source Machinery Became the Outage Vector
The most visible damage was not a Windows desktop compromise or an Azure platform outage in the classic sense. It was a dependency-resolution failure: workflows that referenced Microsoft-hosted GitHub Actions suddenly could not find what they expected to find. That is a quieter kind of outage, but for teams pushing production code through CI/CD, it is just as real.The affected set reportedly included Azure Functions and Durable Task repositories, with Azure/functions-action drawing the most attention because it is not merely a library people browse. It is an action embedded in deployment workflows, the kind of component that sits invisibly inside a YAML file until the day it stops resolving. When GitHub disabled the repository, downstream pipelines did exactly what tightly coupled automation does: they failed.
That distinction matters. A compromised repository can be a security event, but a disabled repository can become an availability event for everyone who treats that repository as infrastructure. The modern open-source cloud stack has blurred the line between source code, release artifact, documentation, deployment tool, and operational dependency.
Microsoft later said the repositories had been restored and that affected customers were notified while investigation work continued. That is the correct procedural ending to the first phase of the incident, but it does not close the larger story. The larger story is that a repository platform’s safety intervention became, by design, a global CI/CD breaker for organizations that had delegated deployment reliability to a live upstream reference.
Miasma Did Not Need to Poison the Package Registry This Time
The reported Miasma campaign is significant because it appears to have moved beyond the familiar registry-poisoning playbook. In the earlier durabletask PyPI episode, malicious versions of Microsoft’s durabletask Python SDK were uploaded to the Python Package Index on May 19 before being removed roughly 35 minutes later. That was bad, but it fit an old model: attackers tamper with a package channel, defenders yank the package, and customers audit dependency versions.The June 5 incident was more unsettling because the attackers reportedly did not need to alter normal source code paths. Researchers said malicious configuration files were planted for tools including Claude Code, Gemini CLI, Cursor, and Visual Studio Code, all pointing toward a multi-megabyte payload. In other words, the trap was set for the developer’s workspace rather than the application runtime.
That is the shift administrators should not miss. The traditional supply-chain conversation asks whether build artifacts, package versions, and container images are authentic. Miasma forces a different question: what happens when opening the repository is itself enough to place a developer’s environment in danger?
AI coding assistants make that question more urgent because they are designed to observe, index, execute, and assist inside exactly the context attackers want to reach. The more capable the tool, the more valuable its privileges become. A coding agent that can inspect a workspace, run commands, invoke package managers, read environment context, and help with deployment is not just a productivity aid; it is a potential execution surface with developer-grade access.
The Durable Task Thread Connects Two Incidents Into One Campaign
StepSecurity and other researchers have linked the Microsoft repository incident to the earlier compromise involving the official durabletask Python SDK. That package reportedly receives hundreds of thousands of downloads per month, which gives the attacker a large target even before Microsoft’s brand enters the equation. The package name also sits in a cloud-development niche where users are likely to have meaningful credentials nearby.The alleged reuse of a compromised contributor path is the connective tissue. If researchers are right, the same broad campaign moved from registry abuse to repository abuse, using trust relationships around Microsoft-maintained open source to find the next opening. That is a familiar escalation pattern in supply-chain attacks: compromise one identity, harvest more secrets, pivot into adjacent projects, and repeat until either automation catches up or a human notices the shape of the intrusion.
The name TeamPCP has been attached to the broader campaign by researchers, and Miasma has been described as a variant or descendant in the same ecosystem as Mini Shai-Hulud. The nomenclature will matter to threat-intelligence teams, but the operational lesson is more important for most readers. The campaign’s strength is not a single exotic exploit; it is the attacker’s ability to exploit the ordinary connective tissue of software work.
That connective tissue is exactly what Microsoft, GitHub, Azure, and the open-source ecosystem have spent years optimizing. Repositories are public, actions are reusable, tokens are portable, agents are helpful, and automation is expected to move quickly. Miasma turned those virtues into propagation opportunities.
GitHub’s Safety Switch Worked, and That Is Why It Hurt
GitHub disabling 73 repositories sounds drastic, but platform operators often have few elegant options once malicious content is found in high-profile projects. Leaving compromised repositories available risks further infections. Taking them offline stops the immediate spread but breaks anyone who assumed the repository would always be reachable.That is the operational paradox at the heart of the incident. GitHub’s intervention appears to have been a containment move, yet containment exposed how much production deployment depends on the continuous availability of upstream repositories. The platform did what a platform must do, and downstream systems paid the price.
For years, defenders have told engineering teams to pin dependencies, use lockfiles, validate signatures, and avoid floating references. GitHub Actions complicate that advice because many workflows still reference major-version tags such as
@v1, a practice that is convenient but fragile. A tag is easier to read than a commit SHA, easier to update than a vendored action, and easier to explain to a team. It is also a live dependency on someone else’s repository governance.The Azure/functions-action disruption shows why that matters. If an action is treated as part of the production release path, then its availability is part of your production release risk. That is not a theoretical purity argument. It is the difference between a deploy pipeline that fails because your code is broken and one that fails because a third-party trust decision changed upstream.
AI Coding Tools Have Inherited the Old Editor Problem at Cloud Scale
Developers have always customized editors, shells, terminals, linters, and project hooks. The difference now is that AI coding tools encourage deeper project intimacy. They want to read more files, infer more context, run more workflows, and sit closer to the act of building and shipping software.That makes configuration files a more attractive target. A malicious package has to enter a dependency graph and survive scanning. A malicious workflow has to be invoked. But a malicious tool configuration can target the moment a developer opens a trusted repository. It exploits habit rather than deployment.
Visual Studio Code has long had workspace trust concepts precisely because project folders can influence editor behavior. The arrival of AI agents raises the stakes because the boundary between “read this repository” and “act on this repository” is becoming less rigid. An agent that can help fix a test, install a dependency, update a workflow, or summarize a codebase may also be in a position to expose secrets if the workspace is hostile.
The uncomfortable truth is that developers increasingly open repositories the way users once opened email attachments. They skim the project, trust the brand, and assume the toolchain will behave. Miasma is a sign that attackers understand that muscle memory very well.
Microsoft’s Brand Magnified the Blast Radius
There is a reason this story landed harder than a random maintainer compromise. Microsoft is not just another GitHub user. It owns GitHub, runs Azure, publishes official SDKs, maintains widely used GitHub Actions, and anchors a large part of the developer tooling universe. When Microsoft-owned repositories are disabled, it shakes assumptions about platform trust.That does not mean Microsoft uniquely failed in some simple way. Large open-source estates are difficult to secure because they involve many organizations, maintainers, service accounts, release systems, bots, and historical permissions. Any company with thousands of public repositories has stale access somewhere, forgotten automation somewhere else, and a steady stream of contributors who need enough permission to get work done.
But Microsoft’s role changes the expectations. Customers use Microsoft-maintained actions and SDKs because they assume the chain is safer than an unknown third-party alternative. They integrate those components into regulated environments, enterprise deployment systems, and production release paths. When that chain breaks, the damage is reputational as well as technical.
The incident also exposes a communications gap. Developers encountering disabled repositories saw GitHub terms-of-service language, broken workflows, and scattered explanations before a coherent picture emerged. That is often how supply-chain incidents unfold, but it is especially painful when the affected components sit in official cloud deployment paths. In the moment, “internal management issue” does not help a release engineer decide whether to rotate secrets, pin a commit, or halt production deployments.
The Risk Was Never Limited to People Who Downloaded Malware
The tempting response to any supply-chain story is to ask whether one’s own systems executed the malicious payload. That is necessary, but too narrow. In this case, the risk landscape includes developers who opened affected repositories, CI systems that referenced disabled actions, and organizations whose secrets may have existed in environments touched by compromised workflows or tools.A developer workstation is often a concentration point for credentials. It may hold cloud CLI sessions, GitHub tokens, package registry credentials, SSH keys, environment files, local caches, and access to internal repositories. The industry has spent years hardening production clusters while leaving developer laptops and build runners as semi-trusted convenience zones.
Build runners are even more dangerous because they are designed to assemble secrets and code at runtime. A CI job may receive deployment credentials only briefly, but briefly is enough if malicious code runs at the right moment. If a worm’s goal is credential theft and propagation, the build environment is not merely collateral. It is the target.
The presence of AI coding tools adds another identity layer. Organizations now need to know which agents are installed, what they can execute, whether they respect workspace trust boundaries, and how their configuration is reviewed. Asset inventory used to mean laptops, servers, containers, and cloud accounts. It now has to include developer agents that can act inside repositories.
The Enterprise Playbook Is Still Too Focused on Packages
Most software supply-chain controls were built around packages and artifacts. They scan dependencies, check known vulnerabilities, enforce lockfiles, produce SBOMs, and block suspicious versions. Those controls remain important, but Miasma shows their limits.If malicious behavior enters through editor configuration, agent configuration, repository hooks, or workspace metadata, a package scanner may never see the first move. If the payload is fetched only when a particular tool opens the repository, the dangerous moment may occur outside CI entirely. And if the attacker’s real goal is to steal tokens, the compromise can succeed before any suspicious dependency appears in a bill of materials.
This does not make SBOMs useless. It means they are incomplete. A software bill of materials tells you what you intended to build with. It does not automatically tell you what your developer tools executed while deciding how to build it.
Enterprise defenders should treat repositories as active content, not passive text. That means reviewing workspace settings, agent instructions, tool-specific configuration files, devcontainer definitions, pre-commit hooks, package-manager scripts, and GitHub Actions workflows with the same suspicion once reserved for executable code. The old division between “code” and “configuration” has collapsed.
Pinning Helps, but It Does Not Save You From Trust
One predictable recommendation after the Azure/functions-action disruption is to pin GitHub Actions to immutable commit SHAs. That is good advice. It reduces exposure to tag movement, accidental breaking changes, and some compromise scenarios. It also makes builds more reproducible.But pinning is not a complete answer. If the underlying repository is disabled, the pinned commit may still become unavailable unless it is cached or mirrored. If the commit was already malicious, pinning preserves the compromise. If the danger lies in a developer opening a repository locally, the CI reference may not be the relevant path at all.
The deeper answer is layered resilience. Enterprises should mirror critical actions, maintain internal allowlists, use artifact caching, enforce token minimization, require short-lived credentials, and isolate build runners from developer workstations. They should also assume that a trusted upstream can disappear suddenly for reasons that are entirely rational from the platform’s perspective.
That last point is cultural. Many organizations treat open-source dependencies as free infrastructure without applying infrastructure-grade continuity planning. If your deployment system cannot function when a public repository is temporarily disabled, then that public repository is part of your availability model whether procurement recognizes it or not.
Windows Developers Are in the Middle of This, Not on the Sidelines
This incident is especially relevant to the Windows ecosystem because Visual Studio Code, Azure Functions, GitHub Actions, PowerShell, WSL, Azure CLI, and Microsoft’s cloud SDKs form a common developer stack for Windows shops. The boundary between local Windows workstation and cloud deployment pipeline is thin. A developer may edit in VS Code, authenticate to Azure, push to GitHub, and trigger production deployment from the same machine.That convenience is the Microsoft developer story at its best. It is also why a repository-level supply-chain attack can matter even if it never touches the Windows kernel, Defender signatures, or a monthly cumulative update. The endpoint is part of the delivery chain.
Sysadmins should resist the instinct to file this under “developer problem.” Developer credentials are often privileged credentials. Developer machines often have access to production-adjacent systems. Developer tools often bypass controls that would be non-negotiable on servers because teams need flexibility to ship.
The practical Windows angle is therefore identity and execution control. Defender for Endpoint, application control, PowerShell logging, Git credential hygiene, conditional access, and privileged access management all have roles to play. But they must be applied with an understanding that the risky process may be a code editor, a terminal, a Node process spawned by an extension, or an AI agent executing inside a workspace.
The Open-Source Trust Model Is Being Repriced
Open source has always run on a strange blend of radical transparency and personal trust. Anyone can inspect the code, but almost nobody inspects all of it. Projects are public, but permissions are private. Maintainers are trusted, bots are trusted, tags are trusted, and release automation is trusted because the alternative is paralysis.Miasma did not invent that problem. It merely exploited the part of the system that had become most valuable: the automation layer around open source. The code repository is no longer just a place where humans collaborate. It is a trigger point for package publication, documentation builds, deployment actions, test infrastructure, AI agents, and cloud release machinery.
That makes Microsoft’s compromised repositories a warning about scale. The more a company standardizes on open workflows, the more any one compromised path can ripple outward. The more the ecosystem depends on canonical actions and official SDKs, the more a temporary takedown becomes a service disruption for strangers.
The answer is not to retreat from open source. It is to stop pretending that openness alone creates safety. Transparency helps after detection; it does not prevent credential theft, malicious configuration, or the misuse of legitimate maintainer access. Trust now has to be continuously verified at the level of identity, repository state, tool behavior, and build output.
The Miasma Lesson Fits in a Release Engineer’s Notebook
The immediate incident will fade as repositories return, advisories age, and teams clear their failed workflows. The durable lesson is more practical than dramatic: organizations need to decide which upstream components are critical, which developer tools are allowed to act on code, and which credentials would be exposed if a trusted repository turned hostile.- Teams that depend on Azure/functions-action or similar official actions should review whether their workflows use floating major-version tags and whether critical actions are mirrored, pinned, or cached internally.
- Developers who opened affected repositories during the exposure window should rotate relevant GitHub, Azure, package registry, SSH, and local development credentials according to their organization’s incident-response policy.
- Security teams should inventory AI coding tools and editor extensions with the same seriousness they apply to CLIs, build agents, and remote-management utilities.
- CI/CD runners should use short-lived, narrowly scoped credentials so a malicious repository or action cannot easily turn one stolen token into a campaign.
- Repository reviews should include workspace settings, agent configuration, devcontainers, hooks, and automation metadata rather than focusing only on application source code.
- Incident communications should distinguish between platform containment, customer exposure, and downstream availability impact so administrators can take action without waiting for rumor-driven timelines.
References
- Primary source: Open Source For You
Published: 2026-06-10T08:30:08.126398
Miasma Worm Disrupts Global CI/CD Through Microsoft Repositories - Open Source For You
A Miasma worm campaign compromised 73 Microsoft GitHub repositories, disrupted global CI/CD workflows and evolved beyond PyPI attacks to target AI coding
www.opensourceforu.com
- Related coverage: techradar.com
Microsoft disables over 70 GitHub repos after hackers compromised them with dangerous malware | TechRadar
Someone forgot to change compromised credentialswww.techradar.com - 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: rescana.com
Miasma Worm Supply Chain Attack: 73 Microsoft GitHub Repositories Compromised via AI Coding Tools – Rescana
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, Microsofwww.rescana.com - Related coverage: data-today.net
Miasma worm turns AI coding agents into repo traps | Data Today
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: 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: iamtzar.com
Miasma Worm Hits 73 Microsoft GitHub Repositories in Major Supply Chain Attack
In what marks the most significant escalation of an ongoing supply chain campaign, the self-replicating Miasma worm compromised 73 Microsoft GitHub repositoriesiamtzar.com - Related coverage: thehackernews.com
Miasma Worm Hits 73 Microsoft GitHub Repositories in Major Supply Chain Attack
Miasma hit 73 Microsoft repos across four GitHub orgs, forcing access disablement and exposing open-source trust risks.thehackernews.com
- Related coverage: awesomeagents.ai
Miasma Worm Compromises 73 Microsoft GitHub Repos | Awesome Agents
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: windowsforum.com
GitHub disables 73 Microsoft Azure repos after “Miasma” editor/AI workspace attack | Windows Forum
On June 5, 2026, GitHub disabled 73 repositories across Microsoft’s Azure, Microsoft, Azure-Samples, and MicrosoftDocs organizations after a malicious...
windowsforum.com
- Official source: microsoft.com
- Related coverage: labs.cloudsecurityalliance.org
CSA research note miasma npm supply chain redhat 20260603 csa styled
PDF documentlabs.cloudsecurityalliance.org
- Official source: download.microsoft.com
Microsoft Security Intelligence Report Volume 15 Regional Threat Assessment Ukraine
PDF documentdownload.microsoft.com
- Official source: learn.microsoft.com
How to disable functions in Azure Functions | Microsoft Learn
Learn how to disable and enable functions in Azure Functions.learn.microsoft.com - Related coverage: investigacion.udem.edu.mx
Is there a global Microsoft outage today?[[[Microsoft Services Status]]]]
PDF documentinvestigacion.udem.edu.mx
- Related coverage: techxplore.com
