- OX Security found hijacked releases of legitimate npm packages. They ask the Ethereum blockchain where to download a further malicious payload.
- OX says attackers can move that server without changing the published package. WebPulse argues that reading the package files cannot show what the fetched stage will do.
- OX advises checking lockfiles, pinning clean versions, adding a minimum package-age policy, and treating wallets as possibly compromised if the code ran.
A hijacked package can send you somewhere the review never looked
Approving a package is a judgment about the files you can read. This campaign adds a second stage that is not in those files. It is downloaded later, from a server the attacker picks.
OX Security researchers found malicious releases of legitimate npm packages. They link the campaign to the PolinRider malware family. The packages were hijacked, so the trusted name was compromised before anything else happened.
What OX Security found
OX says the attackers took over existing packages instead of building new ones. Inside the index.js file, the researchers found a hidden eval(atob(…)) call. In plain terms, it decodes a block of disguised text and runs the result as code.
The decoded text is more than a pointer. OX says it contains cryptocurrency-stealing logic, with the attacker's Ethereum address inside. The malware also downloads a further payload from a remote server.
OX says the malware builds a list of command-server addresses on the fly. The researchers observed four different IP addresses in use. Security teams can find them in the OX report and search their network logs for matches.
OX says the affected packages total about 1,400 weekly downloads. The firm stresses that this measures download activity. It does not measure confirmed infections or executions of the payload.
How the attack works
OX describes a multi-stage chain. Loading an affected package starts a hidden first stage. That stage asks open Ethereum services, known as RPC endpoints, for a blockchain transaction. A command-server IP address is encoded inside that transaction.
The loader then fetches a JavaScript payload over HTTP. OX says the payload is XOR-obfuscated (XOR is a simple scrambling method). The malware unscrambles it and runs it.
Think of a forwarding address at the post office. The letter stays the same, but where it ends up can change. Here, the blockchain entry is the forwarding address. OX says attackers can update the blockchain-based reference to send installations to new infrastructure. The published package stays as it is.
The loader is also masked. OX points to Base64 text and a bootstrap that shuffles characters. The malware runs through "node -i", an interactive Node.js session. OX says this keeps execution in memory and may complicate detection.
What this shows about reviewing dependencies
This is WebPulse's argument, built on OX's description. It is not a finding of the report.
Reviewing these package files can reveal the loader and the stealer logic. It cannot reveal what the second stage will do. That stage sits on a server the attacker can change.
A hijacked package can change where it fetches code without a new release. That is the gap a one-time review does not cover.
OX makes a point about hijacking too. Attackers do not need to build a fake package when they can hijack a real one. A name your team already trusts gives them a head start.
The report limits its own claims. Installing an affected version does not necessarily mean the payload ran. The risk depends on whether the code executed and on what that machine could reach.
What leaders should ask their teams
OX recommends three steps. Each one becomes a question for your engineering lead.
First: can we check our lockfiles for the compromised versions? OX lists them in its report. Second: if an affected package ran, which wallets and credentials could that machine reach? OX advises treating them as potentially compromised.
Third: do we pin dependencies to verified clean versions? OX also suggests a minimum package-age policy. It reduces exposure to newly published malicious releases.
A fourth question is WebPulse's suggestion, not OX's. Outbound connections from build machines to public Ethereum RPC endpoints and unfamiliar IP addresses are worth asking about. Ask whether anyone would notice them today.
Approving a package covers the files you read. It does not cover the server that package may call later.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OX Security.
