13 Malicious Wallet npm Packages: Check Exposure

Short answer: GitHub disclosed 13 malicious wallet npm packages on September 7, 2026. Every published version is affected and no patched versions exist. If any listed package was installed or executed, isolate the system and rotate secrets from a separate, trusted device; deleting the dependency alone is not enough.

The advisories appeared together between 04:56:55 and 04:56:56 UTC. Their names reference wallets, signing, analytics, Solana, Base, or mobile components. That naming pattern may indicate a coordinated cluster, but the public advisories do not attribute the packages to one actor or describe a shared payload. This article therefore treats them as a same-time defensive exposure check, not as a confirmed campaign.

Which malicious wallet npm packages are affected?

The affected package names are:

• scw-mobile
• scw-core
• base-account-core
• base-app-data
• cb-wallet-solana-provider
• cb-wallet-metadata
• cb-wallet-http
• cb-wallet-store
• cb-wallet-env
• cb-wallet-analytics
• cb-wallet-data
• wallet-engine-signing
• wallet-cds-web

GitHub marks the affected range as >= 0 for every package, meaning every version is unsafe. Each advisory lists no patched version. The primary record for scw-mobile (GHSA-h9g8-rwcg-hpmh) was published September 7, 2026; the related records for base-account-core and cb-wallet-solana-provider carry the same date and remediation language.

The npm registry currently exposes security-placeholder metadata for these names. Do not interpret a placeholder such as 0.0.1-security as a fixed release or install it as a test. The safe outcome is that your dependency graph contains none of these package names.

What does GitHub say happened?

The public GitHub advisories classify the packages as malware under CWE-506, Embedded Malicious Code. They do not yet publish payload-level indicators, attacker infrastructure, or a technical root-cause analysis. That limits what defenders can reliably claim about the packages' exact behavior.

GitHub's response guidance is unambiguous: any computer where one of these packages was installed or run should be considered fully compromised. Secrets and keys stored on that machine should be rotated immediately from a different computer. Removing the package is necessary, but GitHub warns that removal cannot guarantee that all resulting malicious software has been eliminated.

This is a malware incident, not a normal vulnerability with an upgrade path. There is no safe version to select and no patch release to wait for.

How can I check whether my project is exposed?

Check source manifests, lockfiles, installed dependency trees, CI logs, build caches, and container layers. A package may be transitive even when it does not appear in package.json.

1. Search manifests and lockfiles without installing anything. From the repository root, search package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, and pnpm-lock.yaml for every package name above. A direct string search is valuable because it does not execute lifecycle scripts.
2. Inspect the existing dependency tree. If dependencies are already present, run npm ls --all, pnpm list --depth Infinity, or yarn why <package-name>. Do not run a fresh install on a system you are trying to preserve for investigation.
3. Review CI and deployment history. Search dependency-install output from September 7 and earlier retained runs. Check whether caches or base images were created while an affected package was resolvable.
4. Check generated artifacts. Browser bundles, serverless functions, containers, desktop packages, and mobile builds may contain bundled code even after a lockfile is changed.
5. Record the result. Capture the exact package name, resolved version, install time, host, job, and artifact before cleanup. That evidence helps scope credential rotation and downstream rebuilds.

For a broader dependency review, use the npm package safety checklist and the malicious npm package response guide.

What should I do if I find one?

1. Stop using the affected host. Disconnect it from sensitive networks and pause deployments produced by it.
2. Do not rotate secrets on that host. Use a separate, trusted device so replacement credentials are not immediately exposed.
3. Revoke and rotate credentials available to the install process. Include npm tokens, GitHub tokens, SSH keys, cloud credentials, CI secrets, signing keys, wallet material, environment variables, and application credentials. Prioritize high-privilege and reusable credentials.
4. Remove the dependency and rebuild from known-good inputs. Delete affected lockfile entries, dependency directories, package-manager caches, compromised build caches, and suspect images. Re-resolve only after confirming the package is gone from the graph.
5. Rebuild systems when compromise cannot be ruled out. GitHub explicitly warns that uninstalling alone may not remove all malicious software. Reimage developer or CI hosts from a trusted baseline when the package ran there.
6. Review audit logs. Look for unexpected repository access, package publication, cloud API use, SSH activity, wallet operations, and new persistence after the suspected install time.
7. Rebuild and redeploy downstream artifacts. Do not merely patch the source branch while continuing to ship an older bundle or image.

Follow your incident-response process and preserve evidence appropriate to your organization. The npm supply-chain attack guide explains how package compromise can cross developer, CI, and production boundaries.

How does a registry firewall help?

A registry firewall sits on the package-install path between npm clients and the upstream registry. When a requested package version matches advisory data, the firewall can reject the request before the tarball reaches a developer machine, CI runner, or coding agent.

InstallSafe uses OSV.dev advisory data to block flagged versions at that boundary. This is useful for the 13 packages here because the unsafe range covers all versions. The same policy can protect human-driven installs, automated builds, and AI agents when they all resolve packages through the controlled registry endpoint.

The limitation matters: advisory-driven blocking begins after an incident is recorded in the underlying feed. It is not zero-hour behavioral detection and cannot prove that a package is safe before disclosure. Teams should combine registry enforcement with lockfile review, least-privilege CI, short-lived credentials, lifecycle-script controls, artifact provenance, and behavioral analysis where the risk justifies it.

You can read how an npm registry firewall fits into a layered control set, or use the free InstallSafe package scan before adding a dependency.

What should teams change after this disclosure?

First, route every package manager through the same policy boundary. A firewall that protects laptops but not CI, containers, or autonomous coding agents leaves important install paths open.

Second, keep dependency permissions narrow. Package installation should not have standing access to production cloud credentials, broad GitHub tokens, wallet keys, or unrestricted npm publishing tokens. Short-lived credentials and isolated build jobs reduce the blast radius if malicious code executes.

Third, make dependency inventory fast. Teams should be able to answer which repositories, lockfiles, caches, builds, and deployed artifacts contain a named package without launching an emergency manual search across every system.

Finally, treat names as untrusted input. Wallet-themed and brand-adjacent names can look plausible in an autocomplete list or an AI-generated command. Verify the publisher, repository, release history, expected scope, and exact package identity before installation.

FAQ

Are all versions of the 13 packages malicious?

Yes. The GitHub advisories list >= 0 as the affected range and provide no patched versions.

Can I fix exposure by upgrading?

No. There is no safe upgrade for these package names. Remove them from the dependency graph and investigate whether they executed.

Is deleting node_modules enough?

No. GitHub says affected computers should be considered fully compromised. Rotate accessible credentials from a clean device and rebuild or reimage systems when compromise cannot be excluded.

Does npm audit always catch malicious packages?

Only after relevant advisory data is available and the tool or service consumes it. Advisory scanning is useful, but it is not a guarantee against newly published, not-yet-catalogued malware.

Are these packages confirmed to be one campaign?

No public primary advisory attributes them to one actor. They were disclosed together and share wallet-oriented naming, but the relationship remains an inference.

Can a registry firewall prevent this type of install?

It can block versions already flagged in its advisory feed before delivery. It should be one layer alongside behavioral detection, least privilege, isolated builds, and incident-response readiness.