Supply Chain Claude Code Launch via LOOM_TASK Binding
A malicious or compromised npm package called @lamemind/loom-deck reads a task file (tasks.md) and uses it to launch Claude Code sessions bound to attacker-controlled instructions via the LOOM_TASK environment variable. This turns the AI coding agent into a way to execute arbitrary commands chosen by whoever controls the task file.
How the attack works
The package is installed in a project and, when run, spawns or is accompanied by process activity referencing loom-deck, LOOM_TASK, or @lamemind. Shortly after, the same session launches a claude or claude-code process, effectively handing the agent a task defined by that file. Optionally, the process reads a file named tasks.md, which supplies the actual instructions the agent will act on. The combination of the package marker followed by an agent launch in the same session is what this detection flags.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- b7f3c1d4-9a25-4e6b-8f10-2c4d5e6a7b91
- Severity
- High
Why it matters
If the task file or environment variable is attacker-controlled, this gives them a path to run arbitrary code through the AI agent, using it as an execution primitive inside the victim's environment.
What you can do
- →Review any project that depends on @lamemind/loom-deck and confirm it was intentionally installed and is trusted.
- →Treat tasks.md and any file feeding the LOOM_TASK variable as untrusted input; restrict who can write to it.
- →Audit CI/test pipelines that export LOOM_TASK or invoke the claude CLI automatically, and lock down where those files come from.
- →Since this rule only reports and does not block, manually investigate flagged sessions to confirm whether the launch was developer-intended or attacker-triggered.
Known benign look-alikes
- A developer who deliberately installed @lamemind/loom-deck and is running it as an intended task orchestrator. The chain is identical to the attack; only intent differs, which is exactly why this rule reports instead of blocking.
- A local repository, worktree or scratch directory whose path contains "loom-deck" or "loom_task" while an unrelated Claude Code session is launched from it.
- A CI or test harness that exports LOOM_TASK to exercise the package, then invokes the claude CLI in the same shell session.
- Internal wrapper scripts named loom-deck that launch claude for legitimate batch work; these will report once per launch and should be triaged by lineage, not silenced by widening the pattern.
- A tasks.md file that exists for unrelated project reasons and is read by a session instance within the window; this only ever adds the optional third stage and never causes a report on its own.