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.
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.
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.
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.
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.
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.
Keyless signing is not a real thing. Trust online is always anchored to keys, even if short lived. Keyless signing just means letting a centralized oracle blind sign for you with trust anchored in a CA key of some kind in most cases, that an unknown number of people can tamper with.
Also GnuPG is not PGP.
My team and I dual PGP sign all packages in stagex with smartcards after confirmed determinstic builds. It works great, and avoids trust in any single party or computer. We even do this for all our python packages as pip will not allow it.
It is a single command with a rust binary to setup a PGP smartcard out of the package, with a backup. (keyfork)
All devs should be PGP signing releases, reviews, and commits so we have a paper trail blackhats cannot inject themselves into.
There are no excuses other than misconceptions and misinformation on this topic being normalized.
That's great - PGP signing works for you in your org.
But the fact is it hasn't worked for package repos like PyPi, and it won't for npm, because in a distributed, low-trust ecosystem like npm, you can't easily bind identities to PGP keys or have any confidence in the key management practices of package signers.
And of course "keyless" signing isn't literally keyless. But tools like sigstore remove the need for the management of long-lived keys and can bind a signature to an identity verified by a trusted IdP, solving some of the main issues with adopting PGP signatures.
I'm so sick of people saying this.
If you use js for any non-tiny project, you'll have a bunch of packages.
Due to how modules work in js, you'll have many, many sub dependencies.
Nobody has time to review every package they'll use, especially when not all sub dependencies have fully pinned versions.
If you have time to review every package, every time it updates, you might as well just write it yourself.
Yes, this is a problem, no reviewing every dependency is not the damn solution
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.
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...
It is by package name, but at least you won't be surprised when left-pad suddenly has an install script.
You can put a fingerprint on the package dependency itself, though, so if you add a fingerprint to anything you approve the install script for, you will get that level of safety.
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.
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.
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.
I if you think that last week attack was s1ngularity that can be related to wormhole, now we get this shai-hulud that is actually a worm. Funny right? They are similar attacks also. This funny coincidence was described by someone at Aikido Security.
So on balance I guess I'll ignore it. What a time to be a developer.