Cryptocurrency packages used at scale should have wallet decoys setup for early detection of vulnerabilities like this.

I see the model of "download any old shit off the internet and run it in production" is working out so well.

Fun fact: installing some common starter packages will explode to install over a 1000 npm packages, each of them can inject malware, even if the package isn’t used, and you’ll never know.

Many packages will have over a 100 dependencies if you include the dev dependencies, so you can easily break a 1000.

That fetch(…) is sending the mnemonic of the private key out to that remote server.

Interestingly if this is happening in a long running process and that exploit server is offline, the promise for the fetch will reject. And the default behavior for unhandled promise rejections would be for the node process to crash.

So if anybody tried testing this version of the library in a net gapped environment, it would crash and fail out in CI.

The attacker should have silenced the error with a .catch(_ => {}).

> Previously only the packed JavaScript code had been modified.

Honestly it's time for the npm ecosystem to move to a model where only build agents running on npm's own infrastructure can upload binary artifacts, or to mandate reproducible builds.

And for a select set of highly used packages, someone from NPM should be paid to look over each release's changeset.

Both would have massively impeded the attacker.