Programming guides for beginner...
Any comments are welcomed....
I hope it helps!!! Thanks for drop by...

Tuesday, June 9, 2026

Miasma Worm Just Hit Microsoft Azure. The 6/8 Post Was the Trailer.

Three days ago, this blog ran a post called "Miasma Worm: Your Settings.json Is a Shell Prompt Now." It argued that the attack surface had moved from package-install hooks to agent-install hooks — that the new surface area is whatever your AI coding tool or IDE executes silently when you open a project. On June 5, 2026, that thesis hit the largest possible target. The Miasma worm campaign reached Microsoft's Azure GitHub organizations. GitHub disabled 73 Microsoft repositories across four organizations in a 105-second automated sweep, per StepSecurity's forensic timeline. The trigger files were the same four files this blog covered on June 8. The payload was the same 4,643,745-byte obfuscated JavaScript dropper. The trailer had its premiere.

What Microsoft actually pulled

Microsoft cut off access to "dozens" of its open-source projects hosted on GitHub, per Zack Whittaker at TechCrunch on 8 June 2026. The reporter count was at least 70. The API-verified count, captured by StepSecurity on 6/5, was 73. Either number is the largest single takedown of a hyperscaler's open-source footprint on GitHub to date, and it happened in an automated 105-second window with no human in the loop.

Microsoft spokesperson Ben Hope told TechCrunch the company has "temporarily removed some repositories as we investigated potential malicious content." Some have been restored after review; others remain offline. Microsoft "notified a small number of customers who may have pulled down content from the affected repositories." Full scope disclosure is still pending.

The disabled set is dominated by the Azure Functions ecosystem. 49 of the 73 disabled repositories are in the Azure GitHub organization, and 35 of those 49 carry the azure-functions- prefix. The list includes azure-functions-agents-runtime, azure-functions-core-tools, azure-functions-docker, azure-functions-dotnet-extensions, azure-functions-durable-extension, azure-functions-durable-js, azure-functions-durable-python, azure-functions-golang-worker, azure-functions-host, azure-functions-java-library, and dozens more. The blast radius is not a single tool. It is an entire Microsoft developer platform's open-source mirror.

The June 5 incident, named and dated

StepSecurity's forensic timeline is precise enough to act on. On June 5, 2026, at 16:00:50 UTC, GitHub's automated abuse detection began disabling repositories. By 16:02:35 UTC — 105 seconds later — 73 Microsoft repositories across four GitHub organizations were returning HTTP 403 with "reason": "tos" (Terms of Service violation). The enforcement was precisely targeted. StepSecurity cross-checked 16 similar Azure Functions repositories not on the list — for example EventGrid, EventHubs, CosmosDB, Redis, ServiceBus, Dapr, plus microsoft/durabletask-python — and confirmed none were blocked. The 73-repository list is the complete attack surface, not a sweep.

The malicious commit was 5f456b8 on Azure/durabletask, pushed using a previously compromised contributor account. The commit metadata is a checklist of red flags:

  • Commit message: "Switched DataConverter to OrchestrationContext [skip ci]"
  • Files changed: 5 added, 0 source code files modified
  • Commit timestamp: Backdated to 2020-03-09T15:59:47Z — six years before the actual push
  • [skip ci] flag: Suppresses CI pipeline execution to avoid automated detection

The commit claims a code change and ships none. All five files are tool configuration or the malicious payload itself. The backdated timestamp hides the commit in a dormant branch. The [skip ci] flag is the killer detail: it makes the attack invisible to the only automated defensive layer most open-source projects actually run.

The same compromised account, three weeks apart

The contributor account used to push 5f456b8 is the same account whose credentials were used in the May 19, 2026 PyPI poisoning of microsoft/durabletask. StepSecurity verified the contributor's personal fork of Azure/azure-functions-durable-extension was also blocked during the same 6/5 sweep (timestamp 16:02:25 UTC), confirming the account was active. Three readings of the same-account reuse are possible:

  1. The account was never fully rotated after May 19. The attacker retained a working GitHub token, and the rotation that should have happened in response to the first compromise did not.
  2. The account was re-compromised by the worm itself. Opening an infected repository in an AI coding tool harvests fresh tokens. The contributor's own development machine, having run the credential stealer on a 5/19-affected package, yielded up new GitHub credentials in the three weeks between incidents.
  3. A different contributor's token was used, with author metadata spoofed via the Git Data API. The fingerprint would be the same; the person behind it would not.

The second reading is the one that should make you set down your coffee. The worm is harvesting the credentials needed to spread itself, on the machines of the people most likely to be trusted by the repositories it wants to compromise next. That is not a supply-chain attack. It is a supply-chain predator, and the hunting ground is the AI coding agent that opened the previous package.

The four trigger files, named honestly

The June 5 incident confirms the four trigger files covered in the 6/8 post are now the primary attack surface for code-stealing in 2026. For the record:

  1. .claude/settings.json — a Claude Code SessionStart hook that runs node .github/setup.js when an agent session opens. A developer who clones an infected repo and starts Claude Code in it has run the payload, with no further interaction.
  2. .gemini/settings.json — identical structure, for Gemini CLI's SessionStart event. Same payload, same auto-run.
  3. .cursor/rules/setup.mdc — a Cursor project rule with alwaysApply: true. This is a prompt injection, not a shell hook. It instructs the Cursor agent to run node .github/setup.js "to initialize the project environment" — language chosen to look like a project setup requirement. The alwaysApply: true flag means the rule fires regardless of which file the developer is editing.
  4. .vscode/tasks.json — a VS Code task configured with "runOptions": { "runOn": "folderOpen" }. No AI agent is required. A senior engineer debugging a vendored dependency, opening the project in their familiar editor, runs the payload.

The fifth file, .github/setup.js, is the credential harvester: 4,643,745 bytes of single-line obfuscated JavaScript that, per SafeDep's static decode, wraps an AES-128-GCM-decrypted async loader pulling environment variables and credential paths for AWS, Azure, GCP, Kubernetes, and 90+ developer-tool configurations. The four trigger files exist only to launch it.

What this is: the supply chain got to Microsoft, not the other way around

The story is not "Microsoft got hacked." The story is "the open-source supply chain got hacked, and a major hyperscaler happened to be downstream of it." The technique does not require a Microsoft contributor. The technique requires a single compromised maintainer account anywhere in a dependency graph whose terminal node is a Microsoft-owned repository. The worm does the rest. Microsoft was the largest target, not the only target. The same fingerprint appears across 123 or more repositories spanning dozens of accounts, per SafeDep's code-search floor (the table is explicitly labeled "floor, not a ceiling"). The icflorescu/mantine-datatable family was compromised the same week, and the loader is a byte-level match for the Miasma family.

The 6/8 post argued that the threat model for 2026 is not "is this package's maintainer trustworthy." The threat model is "does any configuration file in the dependency graph, including files I have never read, execute a payload when one of my AI tools or my IDE opens a project." For most projects, the answer to that question is I do not know, and the answer is honest.

The Microsoft incident adds three more sentences to that threat model:

  • The account that gets compromised does not have to be the account whose code runs. A compromised GitHub PAT from a single developer, used to push a commit, is enough to plant the four trigger files. The credential stealer then runs in the environment of every developer who subsequently opens the project.
  • The "human-in-the-loop" defense does not apply to file-open events. The whole point of the configuration-file attack surface is that it triggers on SessionStart or runOn: "folderOpen". There is no confirmation dialog. There is no AI to ask "did you mean to run this." The payload runs before the developer has finished typing their first prompt.
  • Microsoft, with the resources of the largest security operation in enterprise software, did not catch the malicious commit before it shipped. Detection happened downstream, via GitHub's automated terms-of-service enforcement, hours later. The CI pipeline was bypassed by [skip ci]. The commit sat in a backdated branch until the next mass scan. The 105-second takedown is real, but it is cleanup, not prevention.

What this means for you

  • If you maintain an open-source repository: add a CODEOWNERS rule that requires explicit approval for any commit that adds .claude/settings.json, .gemini/settings.json, .cursor/rules/*.mdc, .vscode/tasks.json, or .github/*.js. These file patterns are the Miasma trigger surface, and they should not be silently mergeable by an active contributor, much less a compromised one.
  • If you build or ship an AI coding tool or IDE: ship a safe-by-default posture for SessionStart hooks and folder-open tasks. Claude Code, Gemini CLI, and Cursor can all be configured to require explicit user confirmation before running a shell command from a project config file. The default should be confirmation, not execution. Microsoft just provided the cleanest possible justification for that product decision.
  • If you use Claude Code, Gemini CLI, Cursor, or VS Code in a work context: the next time you open a third-party repository — especially one you cloned recently — check for these four files before you start an agent session. Five seconds of cat is the difference between a debug session and a credential exfiltration.
  • If you work at a company that ships open-source dependencies: the Miasma family has now compromised a single hyperscaler's open-source mirror, a popular UI library, and 120+ smaller projects in a single month. The expected cost of cloning an untrusted repository, in 2026, includes a credential stealer running on folder open. The cost-benefit on containerized, ephemeral, or remote-development environments just changed.
  • If you write about supply-chain security: the post-Miasma configuration-file attack era is its own era. The trigger surface is configuration files, not package managers. The defenses that worked against preinstall and setup.py hooks do not generalize to SessionStart events. The dependency graph now includes the developer's own .claude/ directory. The threat model has to be redrawn.

What to do this week

# 1. Audit every repo you maintain or contribute to for the four
#    Miasma trigger files. They should not exist in a trusted
#    repository unless your team added them on purpose.
#    find . -type f \( \
#      -path "*/.claude/settings.json" -o \
#      -path "*/.gemini/settings.json" -o \
#      -path "*/.cursor/rules/*.mdc" -o \
#      -path "*/.vscode/tasks.json" -o \
#      -path "*/.github/setup.js" \
#    \)
#
# 2. Add a CODEOWNERS rule that requires review for any commit
#    adding or modifying any of those paths. The blast radius
#    of a single compromised account is now the entire
#    repository's user base, and review is the only mitigation
#    that scales.
#
# 3. Configure your AI coding tools to require explicit user
#    confirmation before running shell commands from project
#    configuration. Claude Code: --permission-mode. Cursor:
#    Agent command allowlist. Gemini CLI: --no-auto-run. The
#    default should be "ask first," not "execute."
#
# 4. Rotate any GitHub PATs that were present on a machine
#    that opened an infected repository on or after May 19,
#    2026. The Miasma loader architecture is constant across
#    waves; the inner dropper is recompiled per victim with
#    rotating AES keys and a fresh SHA256, per SafeDep. If
#    you ran any version of it, rotate.
#
# 5. Move development of untrusted third-party dependencies
#    into a container, a VM, or a disposable environment.
#    The era of "I'll just clone it and poke at it locally"
#    is the era of a folder-open credential stealer.
#
# 6. Read the StepSecurity forensic timeline. It is the most
#    technically precise account of the Microsoft incident
#    and it names the file patterns, the commit hash, the
#    timestamps, and the spread of the same compromised
#    account.
#    https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-again-azure-functions-action-and-72-other-repositories-disabled-after-supply-chain-attack-targeting-ai-coding-agents

The original take: the Miasma family is the new normal, and Microsoft just confirmed it

The 6/8 post argued that the configuration-file attack surface was the next escalation of the open-source supply-chain threat. The Microsoft incident is the confirmation. The largest open-source footprint in enterprise software was compromised by the same four trigger files, in the same week, via the same account whose credentials the same worm family stole the first time around. The 105-second takedown is the cleanup. The [skip ci] commit is the new normal. The next incident will not be in a Microsoft repository. It will be in yours, or in a dependency of yours, planted by a contributor you have never met, and it will fire on folder open in the AI coding tool you use every day.

The corollary: the dependency-graph trust model that open-source maintainers have used since 2010 — trust the maintainer, scan the package, defend the install hook — does not extend to 2026. The new trust model has to cover every file in the repository that an AI coding tool or IDE will read on open, because the new attack surface is the entire repository, not the package manifest. Defending preinstall and setup.py is not wrong, but it is the answer to last year's question. The question this year is "what does the AI coding tool do on session start," and the Miasma family is the answer the threat actors have already given.

The 6/8 post was the trailer. June 5 was the premiere. The next installment is a question of when, not if, and the only variable that changes the answer is whether maintainers, AI tool vendors, and enterprise security teams update their threat models before the next wave ships.

Related reads from this blog

  • Miasma Worm: Your Settings.json Is a Shell Prompt Now — The 6/8 post that named the configuration-file attack surface, the four trigger files, and the prompt-injection vector in Cursor. Three days later, the same family hit Microsoft. The post has now been vindicated at the largest possible scale.
  • Speculative KV Coding: 4× Lossless Cache Compression — A different kind of inference-engineering story, but the same shape: a small, technical change that compounds into a category-level shift. The Miasma family is the same kind of compound move on the attacker side. Small change in the trigger files, large change in the attack surface.
  • Xiaomi Hit 1000 t/s on a 1T Model. The Race Just Changed. — Speed is the new axis. Inference at 1000 tps makes new product categories possible. The Miasma worm is the same kind of axis shift on the security side: the configuration-file attack surface is not new, but the cost-benefit of exploiting it at scale is, and the cost-benefit just changed in the attackers' favor.

Disclosure

This post was researched and drafted with AI assistance. Primary sources are listed in the Sources section above. Every numerical claim, direct quote, and timestamp is taken from a fetched and cached source — the synthesis, the framing, and the "what this means" angles are this post's own. The 70-repository TechCrunch count vs. 73 in StepSecurity is a 6/8 vs. 6/5 snapshot difference (StepSecurity's 73 is the API-verified count); the "more than 120" other affected repositories across dozens of accounts is SafeDep's prose figure, with a 123 floor in their code-search table.

Sources

By Jiro at June 09, 2026
Labels: , , , , , , , , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)