Malicious @not-nemo/crypto-tracker npm releases execute commands
TL;DR — OpenSSF Package Analysis reports that the @not-nemo/crypto-tracker npm package contains malicious behavior, including command execution and network communication to a domain associated with malicious activity.
What happened
@not-nemo/crypto-tracker is an npm package published under the @not-nemo scope. OSV entry MAL-2026-2491, imported from the OpenSSF malicious-packages dataset, reports that OpenSSF Package Analysis identified the package as malicious.
Per the OSV record, the flagged versions are considered malicious because (1) the package communicates with a domain associated with malicious activity, and (2) the package executes one or more commands associated with malicious behavior.
This is operationally important for platform teams because malicious dependency installs can execute during CI builds and developer installs, making detection and containment time-sensitive even when the package is low-popularity.
Who is impacted
- Any environment (developer workstation, CI runner, build container, production image) that installed
@not-nemo/crypto-tracker.
| Item | Source value |
|---|---|
| Ecosystem | npm |
| Package | @not-nemo/crypto-tracker |
| Affected versions (flagged) | 1.0.4, 1.0.6 |
| Published (OSV) | 2026-04-05T14:31:21Z |
| Classification basis (per OSV) | Command execution; network communication to a domain associated with malicious activity |
What to do now
- Remove
@not-nemo/crypto-trackerfrom dependency manifests and lockfiles and ensure it is not present in built artifacts (container layers, vendorednode_modules, cached build outputs). - Identify where it may have executed:
- Search CI logs and build scripts for installs that may have pulled the package (direct or transitive).
- Inventory developer and build environments that might have installed
1.0.4or1.0.6.
- Treat confirmed installs as a potential build-environment compromise and perform environment-specific incident response:
- Review for unexpected process execution during
npm install/pnpm install/yarn installsteps. - Rotate credentials and tokens that were accessible to the installing context (especially CI secrets) if exposure is plausible.
- Review for unexpected process execution during
- Add guardrails to reduce repeat exposure:
- Enforce dependency allowlists / scoped registry policies where feasible.
- Alert on newly introduced packages with unusual versions (e.g.,
99.9.x) or unexpected scopes in PR dependency diffs.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.
