PolinRider Loader Returns in 10 Hijacked npm Packages

Sonatype Research Labs says the PolinRider loader is back, hidden inside 10 hijacked npm packages. The research team found 12 malicious releases on 4 November 2026 and tracks the case as sonatype-2026-010515.

The affected packages cover ordinary developer tasks, from Redux state management to health-check APIs and browser activity tracking. Each one also carries a hidden loader that the package’s normal install process never triggers.

How the PolinRider Loader Finds Its Payload Server

Sonatype says all 12 releases use the same method to find a remote payload server. A hidden script reads a transaction sent from one hard-coded Ethereum wallet, then treats parts of the destination address as an IP address.

From that address, the loader fetches XOR-encoded JavaScript over plain HTTP, then runs the decoded code inside the application process and inside a separate, detached Node process. Six releases hide this loader with Base64 encoding; six use a character-permutation routine and the JavaScript Function constructor instead. Sonatype says the decoded loader body in those six releases is identical.

None of the 12 releases needs an npm install or postinstall script to run. Sonatype says the code can execute as soon as an application loads the affected module, or, in one package, as soon as the bundled service starts.

Sonatype says the same Ethereum wallet and server pattern already appeared in an external researcher’s report on a related campaign in late October 2026. That report tied the same resolver wallet to PolinRider loaders found in compromised GitHub repositories, using a matching pair of retrieval paths and port.

Which npm Packages Carry the PolinRider Loader?

Sonatype published the full list of affected packages and releases. Treat every version in the table below as compromised.

Sonatype says a lockfile entry alone does not prove the loader ran, and an import error does not prove it did not run either. The import can fail after the hidden code already executed.

What Should Developers Do Now?

Sonatype lists five checks for any team that uses one of these packages. The order below matches how fast each check closes exposure.

1. Find affected versionsCheck direct and transitive dependencies, lockfiles, internal npm mirrors, and build records against the table above.
2. Check repository protectionsSee whether your package manager or dependency firewall already blocked these releases, and block all ten going forward.
3. Remove the dependencyReplace affected versions in every project, clear them from internal mirrors and caches, and move to independently verified clean releases.
4. Determine whether the code ranCheck which file your application actually loaded, and correlate that with process and network activity on the host.
5. Rotate exposed credentialsIf the code ran, treat the host as compromised and rotate publishing credentials, source repository access, cloud keys, and CI secrets.

This is the same hijacked-package pattern behind the TanStack npm worm and other recent supply-chain incidents. A trusted package starts running code that its own source never shows in a diff. For background on this attack class, see what counts as a malicious package and the software supply chain compromise technique.