Quantix Finance npm Malware: 10 Packages Steal Secrets - all you need to know

Short answer: Ten npm packages using the @quantixfinance scope were identified as malicious on September 3, 2026. This Quantix Finance npm malware runs during preinstall, searches environment variables for credentials and wallet secrets, and sends the results to a remote host. If version 1.0.0 of any listed package was installed, isolate the affected machine or CI runner and rotate exposed secrets from a clean device.

The public advisories identify malicious packages that use the Quantix Finance name. They do not establish that the real Quantix Finance project, website, source repositories, or social accounts were compromised. Treat this as a package-scope impersonation or dependency-confusion risk unless the vendor publishes evidence of a broader incident.

What is the Quantix Finance npm malware alert?

Amazon Inspector reported ten packages to the OpenSSF malicious-packages repository, and OSV published the authoritative records between 15:51:07 and 15:52:25 UTC on September 3, 2026. Every affected package has one identified malicious release: 1.0.0.

The advisories describe the packages as decoys. Their advertised API, SDK, token, wallet, UI, or configuration functions are empty or no-op stubs. The meaningful behavior sits in a preinstall.js file invoked automatically by npm.

What does the malicious preinstall script collect?

During installation, the script iterates over process.env and selects variables whose names contain broad credential-related terms. The published analysis lists terms such as:

• key, secret, token, and pass
• mnemonic, seed, private, and wallet
• api, rpc, infura, and alchemy
• supabase, database, vercel, and railway
• tron, contract, deploy, env, and url

The script adds the hostname, current working directory, and Node.js version, then sends the JSON payload with an HTTP POST. The destination is hidden as the decimal integer 759017974, which represents IPv4 address 45.61.177.246, on port 61289. Using an integer instead of a dotted IP address can evade simple scanners that look only for URL or IPv4 strings.

Because preinstall runs before normal package use, importing the library is unnecessary. A developer workstation, CI runner, build container, or AI coding environment can be exposed as soon as dependency installation executes lifecycle scripts.

How can you check whether your project is exposed?

1. Search lockfiles and manifests

From each repository root, search tracked dependency files for the scope:

rg -n '@quantixfinance/(api|common|config|contracts|sdk|supabase|token|tron|ui|wallet)' \
  package.json package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml

If Ripgrep is unavailable, use your source-control search or inspect the same files manually. Check every branch that built during the exposure window, not only the current default branch.

2. Ask the package manager what is installed

npm ls @quantixfinance/api @quantixfinance/common @quantixfinance/config \
  @quantixfinance/contracts @quantixfinance/sdk @quantixfinance/supabase \
  @quantixfinance/token @quantixfinance/tron @quantixfinance/ui \
  @quantixfinance/wallet --all

A clean current dependency tree does not prove the package never ran. Review CI logs, dependency-cache records, build artifacts, container layers, and lockfile history for September 3, 2026. Also search for the indicator 45.61.177.246:61289 in proxy, DNS, firewall, EDR, and network-flow logs.

3. Inspect npm install history carefully

Look for installs that resolved 1.0.0, including indirect dependencies introduced by internal package names or automated tooling. Dependency confusion can occur when a build expects a private package but resolves a same-named public package. Confirm that scoped private dependencies are pinned to the intended registry in project and user-level npm configuration.

4. Scan without executing packages

Use advisory and package-intelligence tools that inspect metadata or tarballs without running lifecycle scripts. InstallSafe's free npm package scanner checks packages against OSV.dev advisory data. For a broader review process, use the npm package safety checklist.

What should you do if version 1.0.0 was installed?

1. Stop using the affected host. Isolate the workstation, runner, VM, or container from networks and sensitive systems. Do not rotate credentials from the potentially compromised machine.
2. Preserve evidence. Save relevant build logs, process data, network logs, dependency caches, lockfiles, container digests, and timestamps before rebuilding systems.
3. Identify every reachable secret. Inventory environment variables available to the install process. Include npm and GitHub tokens, cloud credentials, database URLs, deployment keys, Supabase secrets, RPC provider keys, wallet seeds, and private keys.
4. Revoke and rotate from a clean device. Treat matching environment values as disclosed even if outbound traffic is not visible. Revoke tokens before issuing replacements where the provider supports it.
5. Move funds where necessary. If a mnemonic, seed phrase, or private key may have been present, create a new wallet from a trusted clean environment and transfer assets. Rotating an API token does not repair an exposed blockchain private key.
6. Remove the packages and caches. Delete the malicious dependency from manifests and lockfiles, purge relevant package-manager and CI caches, and rebuild from known-good source and base images.
7. Review account activity. Check npm, GitHub, cloud, database, deployment, RPC, and wallet logs for unusual use after the suspected installation time.

Merely uninstalling the package is insufficient. It can stop future executions, but it cannot recall data already transmitted. Rebuilding disposable runners and containers is usually safer than attempting to clean them in place.

How can teams prevent similar npm package attacks?

• Map each private npm scope to its approved internal registry and fail closed when the mapping is unavailable.
• Use lockfiles with immutable or frozen install modes in CI, and review unexpected lockfile changes.
• Disable lifecycle scripts by default where practical, then allow only dependencies that genuinely need build scripts.
• Keep production, signing, wallet, and deployment secrets out of general dependency-install environments.
• Use short-lived, least-privilege credentials on isolated CI runners.
• Review newly created packages, maintainer history, release age, package contents, and unexpected network or process capabilities before adoption.

For more detail on this attack surface, read our guide to checking npm packages safely and the overview of npm vulnerability scanners.

How does a registry firewall help?

A registry firewall sits at the dependency-install boundary. Once an affected version is present in the advisory data used by its policy engine, it can block that exact package release before npm, CI, or an AI agent downloads and executes it. Central enforcement also reduces reliance on every developer remembering a newly published package name.

InstallSafe uses OSV.dev advisory data to block flagged versions and serves byte-for-byte upstream tarballs for allowed packages. It can protect interactive installs, CI, and agent-driven package selection through the registry configuration developers already use.

The limitation matters: advisory-backed controls are not guaranteed to catch a malicious release before researchers publish a record. Behavioral-analysis products may identify suspicious lifecycle scripts or outbound connections earlier. Strong programs combine registry policy, behavioral package analysis, locked dependencies, isolated builds, secret minimization, and incident response.

Frequently asked questions

Was Quantix Finance itself compromised?

The public OSV records do not prove that. They show malicious npm packages under the @quantixfinance name. Until an official vendor statement provides more evidence, describe the incident as malicious packages using that scope, not as a confirmed breach of the project.

Which versions are malicious?

OSV identifies version 1.0.0 of all ten listed packages. No safe release is identified in the advisories.

Does npm ignore-scripts prevent this payload?

Installing with lifecycle scripts disabled can prevent the declared preinstall script from running. It is a useful layer, but teams should still remove the package, inspect past installs, and investigate any environment where scripts may have been enabled.

What secrets should be rotated?

Rotate every secret visible to the install process whose environment-variable name could match the malware's broad keyword list. Prioritize npm, source-control, cloud, database, deployment, RPC, and wallet credentials.

Is uninstalling the package enough?

No. Uninstallation does not invalidate stolen tokens or keys. Isolate the host, preserve evidence, rotate secrets from a clean system, purge caches, and rebuild affected environments.

When was this disclosed?

The authoritative OSV records were originally published on September 3, 2026, between 15:51:07 and 15:52:25 UTC. That year and timestamp were checked directly to avoid mistaking an older incident or later roundup for breaking news.