The Shai-Hulud npm worm showed that opening a folder is enough to run code

In August 2026 an attacker took over the GitHub account of a maintainer who controls widely used npm caching libraries and pushed malicious commits straight into the project's own release pipeline. The resulting package versions carried valid provenance signatures, because they were published by the project's legitimate automation. Within roughly four hours the payload had spread to hundreds of packages. The detail that matters for defenders is how the code ran on developer machines: not through npm install, but through editor and agent configuration files that execute on folder open.

What actually triggered execution

The worm wrote persistence into files such as .vscode/tasks.json and .claude/settings.json. A task definition in the first file can run a command when the folder is opened in Visual Studio Code. A session hook in the second can run a command when a coding agent session starts in that directory. Neither requires the developer to install a dependency, run a build, or approve a prompt.

This changes the threat model for anyone who clones repositories. The traditional advice, that dependencies are dangerous and you should review what you install, assumes installation is the moment of risk. When the trigger is opening a directory, the risky action is browsing code.

Why provenance did not help

The malicious versions were published through the maintainer's normal GitHub Actions workflow. Any control that checks whether an artifact came from the expected build pipeline would have accepted them, because it did. Provenance answers the question "was this built by the pipeline we trust?" It does not answer "was the source that the pipeline built from trustworthy?" An attacker with commit access to the default branch satisfies the first check and defeats the second.

This is not a flaw in provenance tooling. It is a boundary that has to be stated plainly: signing and provenance verify the build path, not the intent of the person who wrote the commit.

What the payload collected

Public analyses of the campaign describe a loader that harvests credentials from local developer environments, CI systems, cloud provider configuration, Kubernetes contexts, and secret managers. It then uses stolen npm publishing tokens to patch other packages the victim can write to, which is how the spread continued, and uses stolen GitHub tokens to modify repositories and workflow files.

Two operational details are worth noting. First, the worm attempted to create a branch and a workflow file that appeared to come from an automated security tool, then downloaded the workflow's output artifact and deleted the run. Second, it read secrets through the platform's own APIs rather than scraping files, which reduces the artifacts left on disk.

What defenders should change

Workspace trust is the first control. Both major editors offer a trust prompt before running workspace-defined tasks, and it should not be disabled for convenience. If it is disabled, the setting is effectively an auto-execute switch for any repository the developer opens.

Agent configuration files deserve the same scrutiny as CI configuration. A .claude/settings.json or equivalent that defines a session hook is executable content. Reviewing it should be part of reviewing a repository, not an afterthought.

Token scope limits the blast radius. A publishing token that can write to every package a maintainer owns turns one compromised account into a supply chain event. Where the platform supports it, publishing should be restricted to specific packages and require an approval step.

Detection has a concrete signature: outbound connections to newly registered domains, unexpected child processes spawned by an editor or agent, and repository commits that touch workflow or editor configuration files without a corresponding code change.

Limits of this account

Package counts and spread timing in this article come from vendor and press reporting of the incident, and they varied between publications as the investigation continued. The specific file paths and the general mechanism were reported consistently. This article does not claim a verified total of affected packages, and it does not attribute the campaign to a named group beyond what the cited sources state.