Snyk's 4 June 2026 analysis of the node-gyp worm and Datadog's 4 August 2026 analysis of the ChainDrop worm agree on one detail: the malware does not stop at node_modules. It writes files into .claude/, .vscode/ and, in the June wave, .cursor/rules/, so the payload runs again when someone opens the folder or starts an AI session. Running npm uninstall does not remove them.
If you responded to either incident by removing the bad package and rotating keys, check that these files are not still in your repositories.
What's affected
Datadog lists the files ChainDrop writes, to up to 50 branches of any repository the stolen token can write to: .vscode/tasks.json, .claude/math_init.js, .claude/settings.json, .claude/setup.mjs and .vscode/setup.mjs. Snyk's list for the June wave: .claude/settings.json, .vscode/tasks.json with a runOn: folderOpen task, and .cursor/rules/setup.mdc.
Because the files are committed, a teammate who pulls the branch can trigger them without ever installing the package.
How to check if you're exposed
git ls-files .claude .cursor .vscode
git log --all --oneline -- .claude .vscode/tasks.json .cursor/rules | head -30
grep -rn "folderOpen" .vscode/tasks.json 2>/dev/null
grep -rn -E "setup\.mjs|math_init|Math_Symbol" .claude .vscode 2>/dev/null
Any of these files that your team did not write is a finding. Check every branch, not just main:
for b in $(git branch -r | sed 's/^ *//'); do git ls-tree -r --name-only "$b" | grep -E '^\.(claude|vscode|cursor)/' | sed "s|^|$b: |"; done
What to do now
- Remove unknown hook files from every branch and delete the branches if they are not yours.
- Do this before rotating credentials. Snyk says to remove persistence before rotating, so the new secrets are not taken again.
- Add a code owners rule for
.claude/,.vscode/and.cursor/, so changes need review. - Treat any machine that opened an infected folder as exposed, and rotate what it could reach.
How this could have been avoided
- Review config files like code. The hooks are executable, and a ruleset requiring review for these paths would have stopped direct pushes from a stolen token.
- Limit what repository tokens can write to. The worm used tokens that could push to up to 50 branches.
- Use workspace trust and disable auto-run tasks on shared developer machines.
- Detect the pattern in CI: fail a build when these directories change in a pull request without an owner approval.
Quick check
Why does npm uninstall not clean up after these worms?
The hook files live in the repository, outside node_modules, so uninstalling the package leaves them in place.
