NPM flooded with malicious packages downloaded more than 86,000 times.
NPM flooded with malicious packages downloaded more than 86k times
#HackerNews #NPM #malicious #packages #security #vulnerabilities #cyber #threats #software #development
ajuvo ✔
boosted
Verwendet ihr #VSCode? Dann sagt Hallo zum #GlassWorm. 😉
Er stiehlt Zugangsdaten und nutzt das, um sich weiter zu verbreiten. Auf euren Rechnern sucht er nach Wallts für Kryptowährungen und installiert #VNC.
Als Backup-C&C-Server wird der Google Calender genutzt.
.png)
Verwendet ihr #VSCode? Dann sagt Hallo zum #GlassWorm. 😉
Er stiehlt Zugangsdaten und nutzt das, um sich weiter zu verbreiten. Auf euren Rechnern sucht er nach Wallts für Kryptowährungen und installiert #VNC.
Als Backup-C&C-Server wird der Google Calender genutzt.
lmao now legitimate security emails from NPM are considered phishing. What a shitshow.
@antfu Thanks for your work to explore #pnpm catalogs. I agree that this is especially useful to document how and when to update certain dependencies.
Some are safe to change (testing and dev deps), and others require careful review (runtime production dependencies with access to sensitive data).
Looking forward to how this develops over time. This could create big improvements for #JavaScript and #TypeScript projects.
🔒 If you publish packages to the npm registry and haven't already seen its new Trusted Publisher feature, please do take a look at https://docs.npmjs.com/trusted-publishers
🎟️ It uses short-lived OIDC tokens to allow CI-based automation of signed publish-with-provenance.
📈 According to https://github.com/sxzz/npm-top-provenance I maintain 6 of the top 50 packages that use this feature, and those 6 packages combined have over 600 million downloads each month!
I'm a few days late to the party, but #npm still doing nothing to convince me it's a good idea. This is nuts. #security
https://www.koi.security/incident/shai-hulud-npm-supply-chain-attack-crowdstrike-tinycolor
Novo ciberataque “Shai-Hulud” propaga-se como um verme e compromete 187 pacotes npm
🔗 https://tugatech.com.pt/t71903-novo-ciberataque-shai-hulud-propaga-se-como-um-verme-e-compromete-187-pacotes-npm
#API #ataque #cascata #CD #CI #ciberataque #Github #google #javascript #linkedin #malware #npm #phishing #riscos #segurança #servidor #software
Ja-ah-ah-n Lehnardt :couchdb:
boosted
cross-posting my little rant about #npm #npmattack #javascript #typescript stuff here:
Random NPM thoughts of the day:
- The primary NPM registry should be obsoleted entirely ASAP
- JSR does not do anywhere near as much as it should, and it's probably too late to fix.
- A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
- All packages MUST be ESM (JSR ok here)
- MUST include docstrings on all publicly-reachable interfaces.
- MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
- MUST have a non-trivial README.
- MUST be tied to a PUBLIC repo.
- MUST NOT have install scripts (yeah sorry, the fight's over)
- MUST clearly include a license, even if the license is "source available, not open source". This restriction MUST NOT limit to OSI's ridiculous list.
- MUST have a name that is scoped to its publishing user/org (@foo/bar)All of the above constraints MUST be checked at publish time.
Furthermore, the registry MUST provide the following, based on this:
- Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
- Autogenerated API docs.
- Lower-traffic packages that have not had a new version in 6 months should be completely delisted. They can be installed, with a warning printed.
- Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
- Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
- Top 1000 packages (maybe more) have all new publishes put on hold for 7 days, and placed into a public review queue, overridden by [tbd?staff?]
- Y'all aren't gonna like this but: package installation should be reasonably throttled. Both to keep costs down, and to encourage people to do something less lazy than "I'm just going to install all 2k dependencies on CI every time I push a docs change". It's wasteful and harmful for many reasons.
I think that's all I got off the top of my head for now.
There's honestly a lot of stuff that could be done on the client side to make life better, too, and y'all know I have a ton of thoughts on that, but I wanted to rant about registries for a bit, esp now that the NPM registry is crumbling.
cross-posting my little rant about #npm #npmattack #javascript #typescript stuff here:
Random NPM thoughts of the day:
- The primary NPM registry should be obsoleted entirely ASAP
- JSR does not do anywhere near as much as it should, and it's probably too late to fix.
- A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
- All packages MUST be ESM (JSR ok here)
- MUST include docstrings on all publicly-reachable interfaces.
- MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
- MUST have a non-trivial README.
- MUST be tied to a PUBLIC repo.
- MUST NOT have install scripts (yeah sorry, the fight's over)
- MUST clearly include a license, even if the license is "source available, not open source". This restriction MUST NOT limit to OSI's ridiculous list.
- MUST have a name that is scoped to its publishing user/org (@foo/bar)All of the above constraints MUST be checked at publish time.
Furthermore, the registry MUST provide the following, based on this:
- Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
- Autogenerated API docs.
- Lower-traffic packages that have not had a new version in 6 months should be completely delisted. They can be installed, with a warning printed.
- Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
- Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
- Top 1000 packages (maybe more) have all new publishes put on hold for 7 days, and placed into a public review queue, overridden by [tbd?staff?]
- Y'all aren't gonna like this but: package installation should be reasonably throttled. Both to keep costs down, and to encourage people to do something less lazy than "I'm just going to install all 2k dependencies on CI every time I push a docs change". It's wasteful and harmful for many reasons.
I think that's all I got off the top of my head for now.
There's honestly a lot of stuff that could be done on the client side to make life better, too, and y'all know I have a ton of thoughts on that, but I wanted to rant about registries for a bit, esp now that the NPM registry is crumbling.
👨💻 The good news is that the industry will take stock of this event and finally come together to solve this issue, and it will never happen again... right? #npm
I'm not sure how I feel about Passkeys/WebAuthn yet. But as far as I understand the current npm situation with compromised packages could have been prevented with phishing resistant 2FA. Combined with trusted publishing [1] this should be a lot harder for malicious actors – at least for this attack vector.
Marc
boosted
Oh no, not again... a meditation on #NPM supply chain attacks
https://tane.dev/2025/09/oh-no-not-again...-a-meditation-on-npm-supply-chain-attacks/
Oh #npm got hacked… or rather, a maintainer of packages like debug and chalk was a victim of a phishing attack 😱
https://tweakers.net/nieuws/238896/npm-packages-met-2-miljard-wekelijkse-downloads-zijn-met-malware-geinfecteerd.html
Stefano Marinelli
boosted
A bunch of packages published by qix in NPM just got backdoored it looks like. Obfuscated code was added like two hours ago. #threatintel #npm
Pro-tip for npm: rather than using a classic access token in your ~/.npmrc file, generate a granular access token that only has read permissions.
That way if something does compromise you, they only get access to the read token and cannot publish on your behalf.
Also, npm now supports trusted publishing: https://docs.npmjs.com/trusted-publishers
This means you don't need a static token in your CI/CD configuration anymore.
Pro-tip for npm: rather than using a classic access token in your ~/.npmrc file, generate a granular access token that only has read permissions.
That way if something does compromise you, they only get access to the read token and cannot publish on your behalf.