Skip to content

npm malware wave in Web3, UI, and banking-scoped packages (GHSA batch)

Signal: GitHub Security Advisories published a May 4 UTC batch of npm malware advisories for scoped packages that look like Web3 helpers, UI components, and banking/internal application libraries. GitHub marks these as malicious code (CWE-506) with no patched version.

Affected packages observed in this batch

May 4 UTC continuation: ecommerce, UI, MCP, and theme-looking packages

GitHub published another malware cluster about 80–110 minutes after the first batch. The same response posture applies: there is no safe patched version; treat any execution as potential host compromise. The new names lean toward ecommerce/theme packages, UI/bootstrap glue, MCP tooling, and generic developer-looking packages, which reinforces the need to review new package names by publisher/provenance rather than by name plausibility alone.

Additional hunt prompts for this continuation:

  • Search lockfiles and package caches for ecommerce/theme names (shopify, theme, honcho, tinfoil) that may have blended into frontend work.
  • Treat pi-exa-mcp and other tool-adjacent package names as especially sensitive in agent/MCP environments because install-time execution may have access to local credentials, tool config, and workspace secrets.
  • Review any recent dependency additions that arrived as one-off helper packages, especially if the package publisher is new, lightly documented, or not tied to the expected upstream project.

May 4 UTC second continuation: payment, activation, and B2B-looking packages

GitHub published another 35-advisory malware cluster around 03:03 UTC. This continuation leans heavily into payment-flow, activation-code, B2B, UI-kit, and organization-like scopes (@google-pay-trust/*, @apple-pay-trust/*, @activation_code/*, @business_promocode/*, @b2b_blocker/*, @ozon-complt/*, @tw-*). Treat these as high-risk because the names may blend into checkout, fintech, growth, or internal frontend work where CI and developer hosts often have production-adjacent secrets.

Additional hunt prompts for this continuation:

  • Search checkout/payment, promo-code, activation, anti-bot, analytics, and UI-kit workspaces for the exact package names above, not just production manifests.
  • Review recent dependency additions that appear to mimic trusted payment providers, internal organization scopes, or feature-specific frontend modules.
  • Prioritize CI runners and developer machines that build payment or B2B flows because they may hold deploy credentials, signing material, payment-provider secrets, and production telemetry tokens.

Why this matters

The package names cluster around application glue code (@w3m-*, @bcs-*, @pyme-web/*) rather than obvious throwaway typosquats. That makes them easy to miss in lockfile review because they can look like normal scoped UI, adapter, session, auth, or chain/network helper packages. Treat any install as code execution in the context of the developer machine, CI runner, or build host that resolved the package.

Triage

  1. Search manifests, lockfiles, SBOMs, package-manager logs, dependency caches, and built artifact metadata for the exact package names above.
  2. Identify every host where npm install, npm ci, package postinstall scripts, tests, builds, or runtime code could have executed while the malicious package was present.
  3. Preserve evidence before cleanup: lockfiles, npm cache entries/tarballs, CI logs, network telemetry, process listings, timestamps, and generated artifacts.
  4. Inventory secrets available to impacted contexts: npm tokens, GitHub/GitLab tokens, cloud credentials, deploy keys, signing keys, OIDC trust policies, .env files, and browser/session tokens on developer workstations.

Containment and recovery

  • Remove the packages from manifests and lockfiles; do not pin to a neighboring package or new version until publisher identity and source provenance are verified.
  • Rotate exposed secrets from a known-clean system; assume tokens present on affected hosts are burned.
  • Rebuild CI runners, build containers, and developer environments that executed the package. Package removal alone is not enough if the host had meaningful privileges.
  • Invalidate dependency caches and rebuild release artifacts from clean dependency state.
  • Review package-publishing, repository, CI/CD, and cloud audit logs for unauthorized publishes, workflow edits, token creation, secret reads, and unusual API calls after the first possible install.

Detection ideas

  • Add temporary high-priority detections for these exact package names in lockfile diffs, dependency review tools, SBOM scans, and package-cache indexes.
  • Hunt around install/build windows for unexpected outbound connections, child processes spawned by npm lifecycle scripts, modified shell profiles, new SSH keys, cron/systemd/launch-agent persistence, and tampered build output.
  • Compare artifacts produced during the exposure window against a clean rebuild; malicious package impact may survive as altered generated code, bundled JS, or published packages.

Durable lesson

Scoped package names can make malware look like ordinary platform glue. For dependency review, treat new scoped packages and new publishers as privileged trust changes: require provenance, owner review, lockfile scrutiny, sandboxed installs, minimal CI secrets, and fast SBOM search when advisories land.

Related checklist: Malicious package response.