MAL-WORM Self-Propagation and Spread
The spread step of an npm worm: code uses a harvested publish or CI token to re-publish poisoned packages, stamp a malicious workflow into other repositories, push commits, or dump the loot into an attacker's gist.
What Vulkro detects
MAL-WORM-001 fires when a token harvest and a propagation sink fall within a few lines of each other in the same file.
- Harvest:
NPM_TOKEN,GITHUB_TOKEN/GH_TOKEN, an.npmrc_authToken. - Sink:
npm publish, a gists API call or Octokitgists.create,git push/git remote add, or code writing a.github/workflows/*.ymlfile.
Either half alone is normal; adjacent, in a repository the author controls, they describe a spread routine. Known release automation (semantic-release, changesets, release-please, lerna) is allow-listed, and the list is kept tight so it cannot hide real payloads. Triggers match comment-stripped source; the allow-list matches raw text, since a header comment naming the release tool is real evidence.
This is proximity, not data flow, and never a certificate of safety.
How to fix
- If the file is not your release tooling, assume the token is spent: revoke the npm and GitHub tokens on that machine.
- Audit recent publishes and workflow files in your repositories, and do not run the clone.
References
See also: Confidence model.
This page is generated by vulkro rules export <out-dir> from Vulkro's built-in detector catalogue. Edits made by hand are overwritten on the next regeneration.