Active NPM supply chain attack: Tinycolor and 40 Packages Compromised

64 pointsposted 12 hours ago
by feross
(socket.dev)

22 Comments

alex_suzuki

an hour ago

Nice little Dune reference in there: The malware installs a Github action if it finds an access token, and names it 'shai-hulud-workflow.yml'. Shai Hulud is the Fremen term for the sandworms on Arrakis.

JonChesterfield

12 hours ago

AI detected potential malware. Plus a bunch of words. Is this a real thing? It does look like all the other npm compromise notes. But the page has AI and potential written on it, so the whole thing may be fabricated, and there are no other comments here.

So on balance I guess I'll ignore it. What a time to be a developer.

feross

8 hours ago

Founder of socket.dev here. “AI detected potential malware” is what we call the alerts generated by our automated malware detection engine that runs on all newly published open source packages in real-time. However, these alerts are reviewed by our threat research team and once a human has confirmed the finding, we upgrade it to “Known malware”.

At this point (given we just published research about this) we've upgraded this threat to Known malware.

So in short:

- “AI detected potential malware” = automated system found something suspicious

- “Known malware” = human confirmed it’s real

The wording is intentional because not every automated hit ends up being true malware. It’s better to give developers early visibility into possible threats, even if they turn out to be benign, than to miss a real attack.

junon

4 hours ago

TIL you're the founder of Socket. Thank you (and your team) for the help last week.

seanieb

11 hours ago

socket.dev is a well known a reputable company, and their founder is pretty well known and trusted too. And looking that their blog post it looks like detected a real attack.

ATechGuy

7 hours ago

Speculating based on another post: "...our investors are pushing us hard to frame it as AI..."

efortis

11 hours ago

Mitigate it with:

  echo "ignore-scripts=true" >> ~/.npmrc
https://blog.uxtly.com/getting-rid-of-npm-scripts

lrvick

5 hours ago

And then the vulnerable code will just move to shell execs in the main library that fire the next time you include the library in your project.

If you do not have time to review a library, then do not use it.

wrs

9 hours ago

Some packages have install scripts that actually need to run (e.g., esbuild).

pnpm refuses to run install scripts from packages you haven’t manually authorized, which helps a bit.

lrvick

5 hours ago

pnpm cannot be built from source without an existing pnpm binary making it ineligible for inclusion in any reproducible Linux distro, for good reason, as there is no way to rule out a trusting trust attack.

Pnpm should be considered for hobby use cases only.

efortis

9 hours ago

Yes, at the end of that blog there are two options for that:

  npm install --ignore-scripts=false package-i-trust
Or, trigger the installation script:

  node node_modules/puppeteer/install.js

wrs

7 hours ago

The pnpm version of this is persistent. You approve the package once, and regular install works thereafter. Which is nice.

DemocracyFTW2

4 hours ago

is that permission tied to a specific version with a specific fingerprint/hash? because if it's not then you could still get a surprise come the next update...

jimmyl02

11 hours ago

this being the 2nd large compromise of the week is not boding well from the NPM ecosystem...

supply chain is and has been the new gold mine for bad actors it seems

seanieb

10 hours ago

There have been practical suggestions that could prevent this but NPM has not yet adopted:

- Prevent publishing new package versions for 24–48 hours after account credentials are changed.

- Require support for security keys.

lrvick

5 hours ago

The most important is just having authors sign their code and packages, and verifying code that is signed on download, like every sane Linux distro goes.

Except NPM rejected this over and over going back to 2013.

https://github.com/npm/npm/pull/4016

andycaine

4 hours ago

Some of the reservations around GPG and PKI are understandable. GPG signing clearly works for OS package managers where there is more control, but it's been a failure on PyPi, RubyGems and Maven.

I'd love to see npm adopt keyless signing like PyPi are doing with https://peps.python.org/pep-0740/.

lelanthran

4 hours ago

>

NPM has bigger problems - no adults in the room! For example, they've been rejecting signed packages since 2014 or thereabouts?

Expect npm repos to be overflowing with AI-submitted crap that will lower the signal substantially due to not having any sort of identify via signing.

kevin_thibedeau

12 hours ago

To avoid LeftPad 3.0 they're going to have to add some sort of signed capabilities manifest to restrict API access for these narrow domain packages. Then attackers would limited to targeting those with network privileges.

aussieguy1234

11 hours ago

They're scanning for credentials. If they can get things like AWS credentials, I would expect to see cloud crypto mining as their next move. So it would be a good idea to keep an eye on your infra if you are affected.

lrvick

5 hours ago

Anyone that has production AWS creds in the same operating system they randomly execute unreviewed code on the internet on should have their access revoked.