How Two Malicious NPM Packages Targeted & Sabotaged Others.

An attacker allegedly gained access to an npm user account and published modules that broke dependents. But why?

On July 12th Harry Garrood posted a personal blog entry outlining deliberate sabotage aimed at the PureScript installer. Two separate dependencies, both owned by a user who goes by @shinnn, targeted the npm package with malicious code using techniques that I've seen in exploits by other attackers. Shinnn claims his account was compromised and that these packages were published without his knowledge.

These attacks differ from most in that there is no obvious value in sabotaging an obscure compile-to-JavaScript language. There’s no bitcoin theft, no crypto mining, no data exfiltration nor any backdoors. This is a pure attack on another project for no value and without value there is no obvious motive. @shinnn has maintainer rights to over 400 popular npm packages. If an attacker gained access to @shinnn’s account there are much better targets than PureScript.

What actually happened?


If you haven’t discovered it yet, PureScript is a functional programming language like Haskell that compiles down to JavaScript, similar to how people use CoffeeScript or TypeScript. It is not a widely used language and it being targeted raises eyebrows on its own.

@shinnn is a developer who has contributed to hundreds of packages and is part of many notable GitHub organizations like babel, node.js, and postcss. Most of these have been set to private since June.

In early June there was a falling out between the PureScript core team and @shinnn due to differing styles of communication and collaboration.


Some timeline details from Harry’s account reproduced here for continuity.

5 June@hdgarrood emails @shinnn thanking him for the work on the package but cites conflict and @shinnn's sole ownership as being a concern for the future. In the email @hdgarrood requests that @shinnn transfer the project to the PureScript core team. After a tense back-and-forth on a since-deleted GitHub issue, the PureScript core team adopts the source code in a new project and @shinnn deletes or makes private the original repository.

8 June — The PureScript team publishes , a rebranded version of shinn’s. The difference in names will become important later.

5 July, around 1300 UTC@hdgarrood publishes version of which depends on .

8 hours later an attacker published version with code that causes to hang by returning an object that performs no action but is designed not to throw an error. Npm has since removed version .

6 July@develop7 opens a GitHub issue on outlining the problem.

9 July, around 0100 UTC@doolse identifies as the cause.

@doolse opens an issue on describing the problem, assumed it is a legitimate bug. @shinnn deletes the issue. He explains this here saying it was a knee-jerk reaction stemming from being upset about the original discussion on the project transfer.

9 July, around 0500 UTC@shinnn publishes version which does not contain any malicious code.

9 July, around 0800 UTC — An attacker publishes version which contains the same targeting logic but a different payload. This payload modifies a separate dependency, , to produce unintended behavior and then rewrites itself locally to remove traces of the malicious code. NPM has since deleted this package.

9 July, around 1100 UTC@hdgarrood, assuming the issue is due to a legitimate bug, publishes a new version of the PureScript installer that bypasses . This does not fix new issues due to the now compromised .

9 July, around 1130 UTC@hdgarrood discovers the malicious code in and reports it to npm's support email. @hdgarrood then publishes a new version of the PureScript installer with all of @shinnn’s dependencies removed.

15 July — When asked for comments, Npm responded that they consider the issue resolved with the removal of those packages despite issuing no security advisories at the time of request. Npm states that @shinnn’s account had been compromised and subsequently restored but declined to comment with any details about what, if anything, was actually restored.

17 July — Npm posts two security advisories, security advisory 1082 & security advisory 1083.

Attack details

Visit Harry Garrood’s post for a line by line walkthrough on the malicious code. Here I’ll go over significant points.


Diff of versions 3.0.1 and 3.0.2

The package depended on by way of .

└─┬ dl-tar
└─┬ load-request-from-cwd-or-npm
└── load-from-cwd-or-npm <<<<<<< compromised package

uses to load the module either locally or from the npm registry. uses in a streaming API so any substituted stream would adhere to the same API. These relationships will be important.

The targeting code recursively looks at the parent module's name or directory structure to determine if it should activate its payload. If encounters a parent whose package name ends in or if the parent includes a directory named then the library will work as normal. This allows @shinnn's own to continue working and also prevents this from being reproducible in a common development environment. If a package other than @shinnn's own installer is using then will return a PassThrough stream instead. is an implementation of a node.js stream that does nothing but pass bytes through unchanged.

The end result is that the PureScript core team’s installer downloads nothing because what should have been a object ends up being a stream that does nothing. No errors are surfaced and the process does not continue.


Diff of versions 1.0.2 and 1.0.3

contains the exact same mechanism of payload activation. The payload searches for a local dependency, again, by way of the obfuscated code on line 26 and then rewrites 's source to remove callbacks with a specific signature. This causes similar behavior in the previous attack and results in a broken installer.

This version also goes out of its way to delete itself locally after it has run which makes the malicious intent far more clear.

So what happened?

There is no direct evidence that @shinnn did this himself. Motive exists, @shinnn felt slighted by the PureScript team trying to take over his tool which resulted in hard truths surfacing about their relationships. The malicious payloads were both designed to protect @shinnn’s packages while sabotaging the PureScript team’s installer. @shinnn also requested the PureScript team enable 2FA as a condition of transfer yet claims he did not have 2FA enabled himself which is a critical part of the account compromise story.

This malicious code was also designed to do minimal damage and extract nothing of value. This is not representative of the vast majority of attacks. There is zero point to these attacks unless you have a personal problem with PureScript.

So @shinnn may not have done this, but someone with similar motivations as @shinnn and access to @shinnn’s npm account did.

Why it matters.

@shinnn is a prolific developer maintaining hundreds of packages. He is a member of respected organizations (nodejs, babel, postcss and others), and submits code to high-profile projects. At best this is a user who has poor account security practices, at worst this is a user who crafted malicious code to explicitly sabotage a project out of spite. Either way trust was abused.

@shinnn’s repositories are his and any use of them is subject to his whim. The packages are open source under a very permissive license and when someone puts packages out in the wild it means they might be used by people they don’t like. There are much better ways at handling conflict than resorting to attacker tactics to sabotage others.

Npm inc’s response is disappointing. They did not issue security advisories until I asked them if there would be a post on this. They did not offer any transparency around the resolution and were not interested in exposing information that would help the community get a better understanding of what happened. I understand that Npm can’t spend time investigating every malicious package but there are basic capabilities that would enable the public to perform a better job on their own. As of this post the npm website doesn’t even list that a malicious version ever existed when you view the version details of a package. This is true for most packages that have been seen such problems.

rate-map version list with the missing 1.0.3 version

The npm registry should start exposing public metadata on whether a package was published through an MFA flow and this should be reported by . Depending on packages that have maintainers without MFA set up is liability. MFA is not a silver bullet but it would be a data point towards accountability. It would enable systems to ensure they are built only from packages that have been published with such safeguards in place.

Security surrounding node.js and the million plus npm packages in the registry is improving but trust is waning and much more still needs to be done.

I write about JavaScript, Reverse Engineering, Security, and Credential Stuffing. Also a speaker, O'Reilly Author, creator of Plato, Director at Shape Security.