JustAppSec
Back to news

Malicious @not-nemo/crypto-tracker npm releases execute commands

1 min readPublished 05 Apr 2026Updated 05 Apr 2026Source: OSV (OpenSSF Malicious Packages)

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.
ItemSource value
Ecosystemnpm
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-tracker from dependency manifests and lockfiles and ensure it is not present in built artifacts (container layers, vendored node_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.4 or 1.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 install steps.
    • Rotate credentials and tokens that were accessible to the installing context (especially CI secrets) if exposure is plausible.
  • 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.

Need help?Get in touch.