Your agents answer to Hades: how one commit hijacks 4 AI coding tools

Executive Summary

The Hades supply-chain worm, the latest evolution of the Miasma and Shai-Hulud lineage, executes a credential stealer the moment a developer opens a cloned repository in Claude Code, Gemini, Cursor, or VS Code - no npm install required. Using a single stolen GitHub token, the worm commits AI coding-tool configuration files (.claude/settings.json, .gemini/settings.json, .vscode/tasks.json, .cursor/rules/) into every repository a victim can push to; several of these hooks fire on session start or folder open with no prompt, at the developer's full permissions. The campaign is active: it reached 73 Microsoft repositories this month and arms a wiper that fires if the stolen token is revoked carelessly. This analysis centers the hook execution vector, corrects a weak attribution signal (the forged claude commit author), and publishes new indicators recovered from the samuelrizerio/setup dropper.

What happens when the repo opens

A developer clones an internal repository a teammate pushed to last week, opens it in an editor, and the AI assistant initializes. Somewhere in that startup a command runs at full account permissions, with no prompt and no confirmation, because the configuration that triggered it is a normal committed project file and the tool is doing what that file says. The developer installed nothing and typed no command; opening the folder was the whole attack.

The features that make AI coding tools collaborative, namely shareable version-controlled config that the tool runs automatically, are the same features that turn a poisoned repository into a detonator. That is the campaign's center of gravity, and it lands while AI-assisted development is still being wired into everyday workflows.

Who this hits, and how easily

The Miasma strain that Hades descends from planted these same files into five repositories belonging to Ionut-Cristian Florescu, including mantine-datatable, a Mantine data table with roughly 1,225 stars and thousands of downstream dependents, forging an identical commit into all five inside a 49-second window. The same worm reached 73 Microsoft repositories across the Azure, Azure-Samples, Microsoft, and MicrosoftDocs organizations, including the Azure durabletask project, where the operator pushed with a previously stolen contributor token. StepSecurity, which discovered and named the Hades campaign and has published the fullest account of it, tracks a parallel PyPI wave of roughly 37 releases across a cluster of bioinformatics and graph-ML packages: ensmallen, embiggen, gpsea, pyphetools, and more. Except where we flag our own findings, the campaign-level detail below follows that analysis and Florescu's firsthand account.

Exploitation needs no special access. The attacker only has to get a poisoned configuration file into a repository a target will open, and the worm does that itself once it holds a single GitHub token. CI/CD runners are the worst case, since the workspace-trust prompts that might stop a task on a laptop are routinely disabled there, so the payload runs unattended and the runner's secrets leave with it.

The scale shows in the two compromised accounts we tracked during the June investigation. Between them the worm had staged on the order of 55 exfiltration repositories holding roughly 88 encrypted credential dumps, most on a single account taken over wholesale, about 2 MB of stolen data across roughly 50 repos. Both accounts went offline mid-investigation, so these numbers are a floor: they count only what we enumerated and snapshotted before takedown.

Background: how AI coding-tool hooks work

(This section can be skipped by anyone already familiar with hook configuration.)

AI coding assistants allow commands to be attached to lifecycle events: when a session starts, before a tool runs, when a folder opens. The purpose is team consistency, since committing the configuration keeps everyone's environment behaving the same way. Claude Code reads hooks from .claude/settings.json, VS Code reads tasks from .vscode/tasks.json, and Cursor reads project instructions from its rules files. Per Anthropic's documentation, .claude/settings.json is the project-scoped, committable settings file, separate from the gitignored .claude/settings.local.json used for personal config.

The behavior Hades exploits is a combination of three properties: the config is committed and travels with the repo, the tool executes it automatically, and command hooks run at the developer's full account permissions, able to read, modify, or delete anything that account can.

The attack surface: five files to run a sixth

The cleanest in-the-wild specimen is the commit forged into Florescu's repositories, which he decrypted and documented from his own compromised repo. The malicious commit touches six files, and five of them exist only to launch the sixth, the payload, through whichever AI tool the victim happens to use:

Opening the repo in VS Code fires the folderOpen task. Opening it in Claude Code or Gemini fires the SessionStart hook. Opening it in Cursor triggers an always-apply rule that tells the agent to run the payload to "initialize the project environment." Running npmtest fires the injected script. Cloning the repo and opening it in a modern editor is enough to detonate.

Claude Code: SessionStart runs before anyone can say no

Claude Code's SessionStart event fires whenever a session begins or resumes: a new session, --resume, --continue, /clear, or after compaction. The injected hook uses a wildcard matcher so it fires regardless of how the session started:

Two documented properties make this effective. First, SessionStart has no decision control. Unlike PreToolUse, which gates a tool call behind the permission system, SessionStart runs at initialization and cannot be blocked through the normal approval flow, so there is no per-action prompt to clear. Second, the hook's standard output is fed into the model's context, which gives the attacker a secondary channel for injecting instructions into the assistant at the start of every conversation.

That second capability is real but conditional. Anthropic's documentation notes that Claude Code wraps injected context in a system reminder, and that text shaped like an out-of-band system command can trip the model's prompt-injection defenses and get surfaced to the operator instead of acted on. The reliable primitive is the command execution, not the prompt steering.

VS Code: folderOpen tasks and the trust dialog people click through

VS Code tasks support "runOn": "folderOpen", which runs a task as soon as the workspace loads:

Microsoft built Workspace Trust to stop this, and Restricted Mode disables automatic task execution in untrusted folders. The gap Hades relies on is human, not technical. Developers click "trust the authors" by reflex for internal repositories, unaware that a compromised colleague's token planted a malicious tasks.json inside an otherwise legitimate codebase. The trust decision is sound. The assumption that an internal repo's authors are trustworthy is what the worm breaks.

Fourteen agents, two execution styles

The payload walks the directory tree looking for rule files and config directories for fourteen AI agents and systems, among them Claude, Codex, Gemini, Copilot, Cline, Aider, Tabby, Amazon Q, Cody, Bolt, and Continue, planting prompt instructions or hooks that trigger a bun run bootstrap when the workspace is loaded or consulted. The Claude Code and VS Code vectors run code directly. The Cursor, Windsurf, Copilot, and Aider vectors steer the model instead, which matters for detection: one set is a shell-execution problem, the other a prompt-injection problem, and the two need different controls.

A plain loader and an obfuscated payload

The first-stage loader is plain by design. It checks for the Bun runtime, installs it if missing (PowerShell on Windows, the official curl | bash installer elsewhere), downloads a JavaScript file from a hardcoded GitHub raw URL, puts Bun on the path, and runs the file. The staging repository is samuelrizerio/setup, and the loader pulls index.js from its main branch.

The choice of Bun is consistent across this malware family. It lets a heavily obfuscated JavaScript payload run without a Node.js install, sidestepping package-manager controls and proxy logging, and, as Florescu notes, it dodges Node-based security monitoring by running under a different runtime. StepSecurity and Socket both report that the payload opens with a plain-text comment aimed not at the runtime but at whatever LLM-based scanner reads the file first. The former describes it coercing a 'clean' verdict, an attack characterized as targeting the model's cognitive logic. Socket describes a second face of the same trick in the _index.js payload: a non-executing comment shaped to trip a safety-tuned model's refusal training, so the scanner balks at the file rather than analyzing the obfuscated code beneath it. One version gets a false 'safe', the other gets no answer at all, and both spend the model's own alignment against the analysis.

The lesson for defenders is that an LLM verdict is one signal, not the verdict. A comment that can argue a scanner into calling a file clean, or into refusing to look, says nothing to a traditional ML or NLP classifier, an entropy or signature check, or a behavioral sandbox. Those belong alongside LLM triage rather than downstream of it, now that the payload is built to aim at the model's training instead of the host.

The public analyses diverge on payload structure, and the difference is real. StepSecurity's deobfuscation of the PyPI-delivered _index.js describes sixteen independently encrypted blobs using AES-256-GCM. Our analysis of the samuelrizerio/setup dropper, and Florescu's independent analysis of his .github/setup.js, both found a two-stage structure encrypted with AES-128-GCM: a small Bun-installer stage and a larger stealer stage. Either two builds coexist in the same campaign, or the analyses captured different variants. We flag the divergence rather than assert the two artifacts are identical.

What the payload does once it runs

The credential-theft and propagation capabilities are documented in detail by StepSecurity and corroborated by Florescu's reverse-engineering. Our own analysis of the dropper and payload was static; we did not detonate the malware to watch these behaviors at runtime. In summary, once running the malware:

• Harvests credentials across clouds and registries: GitHub PATs and the ambient Actions GITHUB_TOKEN, npm, PyPI, RubyGems, AWS (including IMDS and ECS metadata endpoints), GCP, Azure, HashiCorp Vault, Kubernetes service-account tokens, SSH keys, Docker auth, and password-manager material.
• Scrapes runner memory on all three platforms, reading /proc/{pid}/mem on Linux, Mach VM APIs on macOS, and ReadProcessMemory on Windows to lift unmasked secrets out of the Runner.Worker process without touching disk.
• Abuses OIDC and forges provenance. Inside GitHub Actions it mints PyPI and npm publish tokens through OIDC, then builds Sigstore and SLSA provenance bundles (Fulcio, Rekor) so poisoned packages appear to carry valid attested build provenance from the org's official pipeline.
• Injects secret-stealing workflows. Depending on token scope, it plants a workflow named "Run Copilot" (often disguised as .github/workflows/codeql.yml), dumps ${{ toJSON(secrets) }} to an artifact, exfiltrates it, then deletes the run, branch, and deployment record to cover the activity.
• Moves laterally over SSH, parsing ~/.ssh/known_hosts and ~/.ssh/config, then staging the loader and payload on reachable hosts with scp and executing them.
• Persists and arms a wiper, installing an hourly C2 polling daemon plus a second gh-token-monitor service that triggers rm -rf ~/ if the stolen token starts returning HTTP 4xx, meaning if someone revokes it. More on that under mitigations.

How the loop survives package takedown

Put together, the campaign self-perpetuates even after the original poisoned package is pulled:

1. Initial infection. A developer installs a poisoned package, or opens a repo a prior victim seeded. A Python startup hook (a -setup.pth file or an obfuscated __init__.py import hook) or an AI-tool hook fetches Bun and runs the payload.
2. Credential theft. The stealer harvests tokens from memory and disk, including Anthropic API keys.
3. Repository enumeration. Using the stolen GitHub token, it lists every repository the victim can push to.
4. Hook injection. It commits the malicious .claude/, .gemini/, .vscode/, and Cursor and other config files into those repositories.
5. Secondary infection. Another developer clones one of them. Because the config is committed, opening the folder in an AI tool runs the payload.
6. Repeat. The new victim's credentials and repositories feed the next round.

The commit author is a costume

The snapshot below captures samuelrizerio/setup before takedown: setup.js and setup.py added in commit 701c082, authored by claude with the Claude avatar. The setup.py is the first-stage loader that installs Bun and fetches index.js.

The claude author looks like proof that an AI agent built and pushed the malware, but it is not. Claude Code's default leaves the developer as author and only adds a Co-Authored-By: Claude <noreply@anthropic.com> trailer; making the author itself claude takes a deliberate identity override, the documented way to make commits appear as Claude instead of the person running them. The recovered commit object shows the identity was set rather than earned: the author email is the bare legacy claude@users.noreply.github.com, not GitHub's modern ID+username form, and the commit is unsigned (no gpgsig header, git signature status N). Without a verified signature, author and committer are arbitrary strings that bind to no account, so GitHub could only ever have shown the commit Unverified.

Setting identities to blend in is the campaign's habit. Florescu's victim repositories carry commits forged as github-actions <github-actions@github.com>, unsigned; StepSecurity's Microsoft case used a real contributor's stolen PAT, backdated to 2020. The operator dresses each commit in whatever fits its surroundings: claude on a repo full of AI-tool tooling, github-actions on a maintainer's active project. The author field is worth alerting on as a detection heuristic, but it is forgeable and proves nothing on its own. The confirmed claim here is the hook execution vector; the authorship is a tell, not the thesis.

What this changes about the threat model

The previous generation of these worms spread through package-manager lifecycle scripts and native build hooks. Hades moves the same idea up a layer, into the configuration surface of AI coding tools, where execution is triggered by opening or resuming rather than by an explicit human action. Hooks are sold as an enforcement mechanism, a way to keep every checkout behaving the same, but the machinery that faithfully applies a team's policy applies an attacker's instructions just as faithfully. That is the design lesson, and it generalizes past this campaign: committed project configuration that can run shell commands is attacker-controllable input, not trusted team input, and it deserves the scrutiny that lifecycle scripts now get.

The design response is a matter of placement. The trust boundary belongs where the risk sits: around committed, auto-executing config, and around any standing authority an assistant holds to act with a developer's credentials. Automatic execution that fires on folder open or session start is where a trust decision belongs, and an assistant's ability to push to other repositories is the kind of action a sandbox should require confirmation for rather than allow silently.

A second lesson sits one layer above the hooks. Security teams increasingly route suspicious code through LLM-based triage, and the payload treats that judge as part of the attack surface: one comment block coaxes a 'clean' verdict, another trips the model's refusal training so the scan stalls before it reaches the code. Both turn the model's own alignment into the evasion. The point is not that LLM triage is worthless, but that a verdict an attacker can author by writing a comment cannot be the only gate. The same refusal training that makes a model decline harmful input is what the attacker triggers to halt the scan, which is why LLM analysis belongs alongside non-LLM classifiers and behavioral checks rather than in front of them.

What to do

The single highest-value habit: treat committed .claude/, .gemini/, .vscode/, .cursor/, and related agent-config files as executable code from an untrusted source, and review them before a cloned repository is opened in any AI tool.

The wiper inverts the usual reflex, so handle it first. The gh-token-monitor service triggers a destructive rm -rf if the stolen GitHub token returns a revoked or 4xx status, within a roughly 72-hour active window. Revoking the token first on a host that may still be infected can set off the wiper. The safer sequence on a suspect host: isolate it from the network, then remove the persistence before touching the credential, namely the user-level systemd services (update-monitor.service, gh-token-monitor.service) or macOS LaunchAgents (com.user.update-monitor.plist, com.user.gh-token-monitor.plist), the wiper script ~/.local/bin/gh-token-monitor.sh, and the stored token at ~/.config/gh-token-monitor/token. Revoke the token once the daemon can no longer act on the revocation.

For developers using AI coding tools

• Inspect a freshly cloned repo for the backdoor files listed below, especially SessionStart hooks and folderOpen tasks, before opening it in an assistant.
• Keep VS Code Workspace Trust enabled and let Restricted Mode block folderOpen tasks in unfamiliar folders.
• Narrow what an assistant may do without confirmation, particularly committing and pushing.
• After installing any flagged package, rotate the full set of targeted credentials, but only after confirming the wiper daemon is absent (see above).

For teams building AI-powered developer tools

• Treat project-scoped configuration as untrusted input. Require an explicit trust decision before executing committed hooks or tasks on first open, and do not run auto-execution config ahead of that decision.
• Add friction to agent-initiated git pushes and cross-repository writes. These should be confirmable, not silent.

For security teams

• Inventory the agent supply chain. Track which hooks, MCP servers, and skills are installed across developer machines and CI, who introduced each, and whether each still does only what it claims. A new SessionStart hook or MCP server deserves the same scrutiny as an unexplained cron job, and a config that predates the campaign is not automatically safe.
• Scan repositories for SessionStart hooks and folderOpen tasks and alert on their introduction. The file list below is a starting signature set.
• In CI, runtime runner protection that detects Runner.Worker memory reads and locks down the step is the control that directly counters the memory-scraping stage.
• Alert on agent-identity commits (for example claude@users.noreply.github.com) and on github-actionsauthored, unsigned commits with the message "chore: update dependencies [skip ci]", while remembering author strings are forgeable.
• In managed Claude Code environments, allowManagedHooksOnly lets administrators block user, project, and plugin hooks in favor of vetted ones.
• Do not treat an LLM scanner's verdict as sufficient. The payload is engineered to manipulate it, so pair LLM triage with traditional ML and NLP classifiers, entropy and signature checks, and behavioral sandboxing that a planted comment cannot influence.

How Pillar Helps

Closing this gap is what we built Pillar for AI Coding Agents for. It discovers the coding agents running across an environment, inventories their hooks, MCP servers, and skills, and flags risks in the AI supply chain - including auto-run hooks and excessive permissions - before they execute. At runtime, it watches for prompt injection and exfiltration. A committed SessionStart hook like the one Hades plants would surface in the inventory the moment it lands in a repo, not the moment it runs.

‍

Indicators of compromise

For the full campaign indicator set, the sentinel and lock files, the Linux and macOS persistence and wiper paths, the repo-backdoor file list, the planted "Run Copilot" workflow, the C2 search keywords, and the forged github-actions commit fingerprint, see StepSecurity's Hades analysis and Florescu's account. We do not reproduce them here. The indicators below are what our own analysis of the samuelrizerio/setup dropper adds, and we have not seen them in public reporting as of June 9, 2026.

Capture note. The samuelrizerio/setup staging repo was cloned intact on June 9, 2026, about three days after the attacker's commit and before the account was removed. Its reflog shows a single clone with no local fetches, checkouts, or rewrites, so the commit and tree metadata below match what landed from origin, though the live repo now returns 404. The other attacker-controlled accounts were taken down before their contents could be fully preserved, so the broader account and exfil-repo observations are point-in-time.

File hashes (samuelrizerio/setup)

The payload is setup.js (about 4.9 MB). setup.py is the small Python loader.

GitHub accounts used in the campaign

The footprint we observed sits on two compromised accounts. Public reporting indicates the operator works through previously compromised accounts rather than newly registered ones: SafeDep and Wiz attribute the June 8 open-sourcing of the toolkit, via repositories named Miasma-Open-Source-Release, to several such accounts. We name only samuelrizerio, the account behind the setup dropper shown above, and leave the second compromised account unnamed.

The counts are conservative: both accounts went 404 mid-investigation, so they reflect only what we enumerated from the event stream and snapshotted, not the full footprint.

samuelrizerio's six exfil repos all follow the underworld scheme: sepulchral-thanatos-4253, stygian-hecate-67962, charonian-charon-77503, nekyian-cocytus-91397, cimmerian-lethe-23916, and acheronian-charon-17597. We cloned four (thanatos, hecate, charon, cocytus) with their results/ dumps plus the setup dropper; the other two appear only in the event stream. The second account was a full takeover, its 50th repo (tenebrous-hecate-24347).

Exfil repo naming

StepSecurity published the scheme and two examples (stygian-cerberus, tartarean-charon). We recovered the larger word lists below, but they are not exhaustive: the live repo tenebrous-hecate-24347 uses an adjective (tenebrous) outside our set. Detection should match the shape {adjective}-{noun}-{0-99999} rather than a fixed vocabulary.

• Adjectives observed (14, not exhaustive): stygian, tartarean, nekyian, charonian, erebean, plutonian, cimmerian, lethean, funereal, abyssal, chthonic, sepulchral, acheronian, chthonian, plus tenebrous seen live
• Nouns observed (14): cerberus, charon, styx, lethe, thanatos, persephone, hecate, cocytus, acheron, asphodel, tartarus, eidolon, erebus, wraith
• Exfil file path: results/results-{unix_timestamp_ms}-{sequence}.json

Network: the Anthropic decoy

GitHub is the sole live C2 channel; there is no traditional C2 domain. Among the endpoints the payload contacts, one is a decoy not previously called out: a POST to https://api.anthropic.com/v1/messages, used to blend the malware's outbound traffic with legitimate AI-tool API calls. The legitimate registry, cloud, and Sigstore endpoints it touches (GitHub API, npm, PyPI, RubyGems, Fulcio, Rekor) are expected for the documented capabilities.

What we did and didn't confirm

We analyzed the samuelrizerio/setup dropper and the config-injection behavior, verified the Claude Code and VS Code mechanisms against vendor documentation, and recovered the new indicators below, including the unsigned status of commit 701c082. The credential theft, memory scraping, provenance abuse, workflow injection, SSH lateral movement, and wiper are documented by StepSecurity and corroborated by Florescu; our own analysis was static, and we did not detonate the payload to watch them at runtime. The staging repo was captured intact, so its metadata is verifiable from our clone, while the account and exfil-repo observations are point-in-time. As noted above, the two-stage AES-128-GCM structure we saw may be a different build from the sixteen-blob AES-256-GCM variant. We have no evidence of any specific organization breached through the hook vector beyond the cases in public reporting.

Timeline

Dates are drawn from the sources cited below.

• Late 2025: the Shai-Hulud npm and GitHub worm first spreads, then returns in November as "Shai-Hulud 2.0."
• Early 2026: Mini Shai-Hulud and Miasma variants spread across npm and PyPI through package-manager lifecycle scripts and native build hooks.
• June 3, 2026: Miasma forges an identical commit into five of Ionut-Cristian Florescu's repositories within a 49-second window (per his account).
• June 5, 2026: GitHub disables 73 Microsoft repositories after a Miasma commit to Azure/durabletask, pushed with a stolen contributor token (per StepSecurity).
• June 6, 2026: the samuelrizerio/setup staging repo commit (701c082) is created.
• June 8, 2026: the PyPI wave (ensmallen 0.8.101 and related packages) is identified and tracked as Hades by StepSecurity and Socket.
• June 9, 2026: we clone samuelrizerio/setup intact before the account is removed.

The Takeaway

Hades is a supply-chain worm that uses developer tooling instead of fighting it. It does not break the AI assistant's security model so much as walk through a door that collaboration features leave open: committed config that runs on open, and an assistant that acts with its operator's credentials. The fix is not a new product but a relocation of trust, onto committed executable config and onto the standing authority an assistant holds to act on a developer's behalf. That boundary is worth drawing before the next variant decides which repositories are worth committing to.

References

1. StepSecurity. The Hades Campaign: Graph ML PyPI Packages Deploy Cross-Platform Memory Scrapers, AI Analyst Misdirection, and a Wiper Deterrent. https://www.stepsecurity.io/blog/the-hades-campaign-pypi-packages
2. StepSecurity. Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled. 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
3. Ionut-Cristian Florescu. The Bot That Never Was (firsthand Miasma incident account). https://codeberg.org/icflorescu/miasma-github-incident
4. SafeDep. Miasma Worm Targets AI Coding Agents via GitHub Repos. https://safedep.io/miasma-worm-ai-coding-agent-config-injection/
5. Socket. Mini Shai-Hulud, Miasma, and Hades Worms Target Bioinformatics and MCP Developers. https://socket.dev/blog/mini-shai-hulud-miasma-and-hades-worms-target-bioinformatics-and-mcp-developers-via-malicious
6. The Hacker News. Hades PyPI Attack: 19 Packages Poisoned to Auto-Run Bun Credential Stealer. https://thehackernews.com/2026/06/hades-pypi-attack-19-packages-poisoned.html
7. Rescana. Active Exploitation Alert: Shai-Hulud Supply Chain Attack. https://www.rescana.com/post/active-exploitation-alert-shai-hulud-supply-chain-attack-compromises-100-npm-and-pypi-packages-with-self-spreading-malwa
8. Anthropic. Claude Code Hooks Reference. https://code.claude.com/docs/en/hooks
9. Microsoft. Tasks in Visual Studio Code and Workspace Trust. https://code.visualstudio.com/docs/editor/tasks and https://code.visualstudio.com/docs/editor/workspace-trust

‍