For the complete documentation index, see /llms.txt. Markdown version of this page: /en/insights/ai-security/shai-hulud-npm-worm-spreads-through-ai-coding-tools.md.
AI Security ↗

Shai-Hulud brings editor configuration into the supply-chain review

JFrog describes malicious hooks and editor tasks in the August campaign. Review executable project settings as well as package dependencies.

AI-generated illustration: Developer checking package provenance before an npm installation.

The cover image is an AI-generated editorial illustration. Screens and documents are illustrative concepts.

A repository can contain instructions that run through an editor or coding assistant, as well as code you deliberately build. JFrog’s August Shai-Hulud analysis describes malicious project configuration, including editor tasks and Claude Code hooks, alongside the package-installation route.

The execution conditions depend on the tool, its version and its trust settings. Cloning a repository is not, by itself, proof that a payload ran. The useful question is what the local tooling was allowed to execute after the project arrived.

Review what starts automatically

Include project-level tasks, hooks and startup configuration in code review. A familiar settings filename should not exempt shell commands or downloaded scripts from scrutiny.

We recommend inspecting an unfamiliar repository in a restricted arrangement before enabling its automation. Keep the credentials available to that environment narrow. An editor session used to inspect unknown code should not casually inherit package-publishing or production access.

For the CI pipeline, understand which installation steps may execute package scripts and which credentials are present at that moment. A compromised dependency becomes more damaging when the build also holds broad publishing rights.

Investigate possible exposure

If the project used an affected package or configuration, follow the indicators and remediation guidance in the research and relevant advisories. Determine what ran, on which machines, and which credentials were accessible.

Removing the malicious file is not a complete response if a token may already have been copied. Revoke affected credentials, examine subsequent use and rebuild compromised execution environments as required by the incident assessment.

Keep the scope evidence-based. A dependency appearing in a lockfile, a malicious script being executed and a credential being used elsewhere are different findings.

This campaign is a reason to widen supply-chain review beyond the dependency list. The configuration that tells a development tool what to run deserves the same attention as the code it helps develop.

← Back to all insights
Questions or inquiry? [email protected] Contact us →