Topic starter
22/06/2026 10:17 am
TL;DR: Hades turns committed AI coding-tool configuration into an execution path, triggering credential theft and payload delivery when a cloned repository opens in Claude Code, Gemini, Cursor, or VS Code, according to Pillar Security. The campaign shows that repo-open trust assumptions, not just package installs, now define the attack surface for developer AI workflows.
Editorial analysis by NHI Mgmt Group, based on content published by Pillar Security: “Your agents answer to Hades: how one commit hijacks 4 AI coding tools”.
By the numbers:
- The campaign reached 73 Microsoft repositories this month.
- Between them the worm had staged on the order of 55 exfiltration repositories holding roughly 88 encrypted credential dumps.
Key questions
Q: What breaks when AI-generated code is only checked after commit?
A: Post-commit controls miss the moment when risky code is created, so secrets, insecure patterns, and policy violations can enter the repository before security ever sees them.
Q: Why do repository-open attacks matter more than install-time supply-chain attacks?
A: Because they fire earlier in the workflow and need less user intent.
Q: What signs indicate malicious AI assistant configuration in a codebase?
A: Look for newly added SessionStart hooks, folderOpen tasks, always-apply rules, or repository-scoped files that launch shell commands without user confirmation.
Practitioner guidance
- Review auto-executing AI tool files before first open Inspect .claude/settings.json, .gemini/settings.json, .vscode/tasks.json, Cursor rules, and similar project-scoped files before opening a cloned repository in any assistant or editor.
- Separate trusted workspaces from untrusted clones Use a quarantine workflow for newly cloned repositories so that workspace trust, auto-run hooks, and assistant initialization cannot execute before human review.
- Harden CI/CD runner permissions and secrets exposure Assume a poisoned repo can execute unattended in runners, and reduce ambient access so runner credentials, deployment tokens, and cloud secrets are not exposed to folder-open or session-start actions.
Bottom line: Committed AI coding-tool hooks turn repository content into executable input, which means repo-open can be the attack trigger rather than a harmless navigation step.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/06/2026 11:06 am
Committed AI coding-tool configuration is now executable supply-chain input, not harmless workspace metadata. The attack works because project-scoped settings can trigger commands automatically when a repo opens or a session starts. That collapses the old assumption that only package managers and build scripts deserve execution scrutiny. Practitioners should treat editor and assistant configuration as part of the code execution boundary.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should security teams contain a poisoned repository after discovery?
A: Freeze the repository, isolate affected runners or workstations, and remove any auto-executing assistant configuration before restoring trust. If a stolen token may still be active, assume it can spread the same configuration into other writable repositories.
👉 Read our full editorial: Hades supply-chain worm shows AI coding tool hooks are executable risk