#npm

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Just checked back on the Sha1-Hulud virus/worm. FINALLY npm appears free of obviously infected packages.

I still however am seeing infected machines posting their private data publicly on GitHub.

Not only that, I can see infected developer's github repos are being defaced in realtime.

These microsoft owned platforms seem to be really struggling with stopping this worm.

Query for defaced repos 👇🏿

github.com/search?q=api.airfor

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

I was able to track down 3 out of the remaining 5 affected packages and posted bug reports & security alerts to those developers I located.

Sure would be nice if NPM and GitHub did this automatically.... kinda feel like I've done an awful lot of free labor for Microsoft this week.

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Is NPM still dangerous?

Yes, we're down to five known infected packages still circulating on the Microsoft owned platform.

The following five packages continue to spread the Sha1-Hulud worm with no warning at all on the NPM page nor at download/install time:

hyper-fullfacing 1.0.3

@ifelsedeveloper/protocol-contracts-svm-idl 0.1.2

quickswap-ads-list 1.0.33

@seung-ju/react-native-action-sheet 0.2.1

tcsp 2.0.2

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Running my NPM checks again today, I see eight remaining infected packages still circulating on the Microsoft owned platform.

Unlike nodejs package index socket.dev NPM does not show ANY security warnings on these package's pages.

It's pretty wild that these known compromised packages have been circulating for four days now with now response or action from Microsoft despite it being one of the largest security stories this month.

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Now that the acute phase is slowing there's a VERY important question...

What is actual fucking value does Microsoft (a trillion dollar company) owning GitHub & NPM bring at all?

This shit was an absolute corporate buyout disaster. How the ever living fuck has microsoft owned NPM for FIVE years and still not done proper MFA requirements for publishing packages on NPM.

How the actual fuck are well known vulnerable packages STILL being propagated by NPM.

A three panel meme

Top - "Hack the planet" shouts a man being forced into a police car

Center - A hacker in a ski mask at a computer works. "Some dune nerd"

Bottom - "Wait, no not like that!" -Microsoft
ALT text detailsA three panel meme Top - "Hack the planet" shouts a man being forced into a police car Center - A hacker in a ski mask at a computer works. "Some dune nerd" Bottom - "Wait, no not like that!" -Microsoft
nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Running my NPM checks again today, I see eight remaining infected packages still circulating on the Microsoft owned platform.

Unlike nodejs package index socket.dev NPM does not show ANY security warnings on these package's pages.

It's pretty wild that these known compromised packages have been circulating for four days now with now response or action from Microsoft despite it being one of the largest security stories this month.

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

These sorts of NPM worms have been around for a LONG time.

It's typically due a common practice of low 2fa opt-in on NPM accounts.

So be sure to setup NPM 2FA if you're a package maintainer do that asap!

A lesser known NPM capability is that you can disable install time scripts. This may break some packages but its worth a try to see if your projects can work with out any install scripts. 👇🏿

blog.npmjs.org/post/1417028810

Package install scripts vulnerability
Disclaimer: we had been told this vulnerability would be disclosed on Monday, not Friday, so this post is a little rushed and may be edited later.

As disclosed to us in January and formally discussed in CERT vulnerability note VU#319816, it is possible for a maliciously-written npm package, when installed, to execute a script that includes itself into a new package that it then publishes to the registry, and to other packages owned by that user.

npm cannot guarantee that packages available on the registry are safe. If you see malicious code on the registry, report it to support@npmjs.com and it will be taken down.

How to protect yourself
If you are installing a package that you do not trust, you can avoid this vulnerability by running

npm install --ignore-scripts

If you wish to never run scripts at install time, you can instead run

npm config set ignore-scripts true

Either or both of these steps will prevent you from spreading a worm at install time.

If you install a package that contains malicious code and then execute it (e.g. by require()ing it into your code) it could still perform malicious actions. You should not execute any software downloaded from the Internet if you do not trust it, including software downloaded from npm.
ALT text detailsPackage install scripts vulnerability Disclaimer: we had been told this vulnerability would be disclosed on Monday, not Friday, so this post is a little rushed and may be edited later. As disclosed to us in January and formally discussed in CERT vulnerability note VU#319816, it is possible for a maliciously-written npm package, when installed, to execute a script that includes itself into a new package that it then publishes to the registry, and to other packages owned by that user. npm cannot guarantee that packages available on the registry are safe. If you see malicious code on the registry, report it to support@npmjs.com and it will be taken down. How to protect yourself If you are installing a package that you do not trust, you can avoid this vulnerability by running npm install --ignore-scripts If you wish to never run scripts at install time, you can instead run npm config set ignore-scripts true Either or both of these steps will prevent you from spreading a worm at install time. If you install a package that contains malicious code and then execute it (e.g. by require()ing it into your code) it could still perform malicious actions. You should not execute any software downloaded from the Internet if you do not trust it, including software downloaded from npm.
nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Just finished writing another tool, now I can see NINE known compromised packages are still up for download on NPM! ⚠️

This tool crawls the list of known bad packages and downloads the latest bundle.

It then runs my other checks against the downloaded bundle and logs the results.

github.com/datapartyjs/walk-wi

./is-npm-still-dangerous
Reads the data/infected-pkgs.txt
Downloads the latest package metadata for every known infected package
Downloads the current latest package.tgz
Uncompresses and scans the latest version using ./check-projects
Depending upon the scan result
./is-npm-still-dangerous

capacitor-voice-recorder-wav 6.0.3 - STILL COMPROMISED
haufe-axera-api-client 0.0.2 - STILL COMPROMISED
hyper-fullfacing 1.0.3 - STILL COMPROMISED
@ifelsedeveloper/protocol-contracts-svm-idl 0.1.2 - STILL COMPROMISED
my-saeed-lib 0.1.1 - STILL COMPROMISED
quickswap-ads-list 1.0.33 - STILL COMPROMISED
@seung-ju/react-native-action-sheet 0.2.1 - STILL COMPROMISED
tcsp 2.0.2 - STILL COMPROMISED
web-types-lit 0.1.1 - STILL COMPROMISED
web-types-lit 0.1.1 - STILL COMPROMISED
Found 9 npm-reports/npm-latest-bad.txt packages STILL compromised!

See npm-reports/npm-latest-bad.txt for full listing.
Warning - Most people probably don't need to run this. It causes a lot of NPM traffic. Warning - There's a few packages this fails to download and check (likely bc's they are hosted outside of NPMjs.org)
ALT text details./is-npm-still-dangerous Reads the data/infected-pkgs.txt Downloads the latest package metadata for every known infected package Downloads the current latest package.tgz Uncompresses and scans the latest version using ./check-projects Depending upon the scan result ./is-npm-still-dangerous capacitor-voice-recorder-wav 6.0.3 - STILL COMPROMISED haufe-axera-api-client 0.0.2 - STILL COMPROMISED hyper-fullfacing 1.0.3 - STILL COMPROMISED @ifelsedeveloper/protocol-contracts-svm-idl 0.1.2 - STILL COMPROMISED my-saeed-lib 0.1.1 - STILL COMPROMISED quickswap-ads-list 1.0.33 - STILL COMPROMISED @seung-ju/react-native-action-sheet 0.2.1 - STILL COMPROMISED tcsp 2.0.2 - STILL COMPROMISED web-types-lit 0.1.1 - STILL COMPROMISED web-types-lit 0.1.1 - STILL COMPROMISED Found 9 npm-reports/npm-latest-bad.txt packages STILL compromised! See npm-reports/npm-latest-bad.txt for full listing. Warning - Most people probably don't need to run this. It causes a lot of NPM traffic. Warning - There's a few packages this fails to download and check (likely bc's they are hosted outside of NPMjs.org)
nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Just finished writing another tool, now I can see NINE known compromised packages are still up for download on NPM! ⚠️

This tool crawls the list of known bad packages and downloads the latest bundle.

It then runs my other checks against the downloaded bundle and logs the results.

github.com/datapartyjs/walk-wi

./is-npm-still-dangerous
Reads the data/infected-pkgs.txt
Downloads the latest package metadata for every known infected package
Downloads the current latest package.tgz
Uncompresses and scans the latest version using ./check-projects
Depending upon the scan result
./is-npm-still-dangerous

capacitor-voice-recorder-wav 6.0.3 - STILL COMPROMISED
haufe-axera-api-client 0.0.2 - STILL COMPROMISED
hyper-fullfacing 1.0.3 - STILL COMPROMISED
@ifelsedeveloper/protocol-contracts-svm-idl 0.1.2 - STILL COMPROMISED
my-saeed-lib 0.1.1 - STILL COMPROMISED
quickswap-ads-list 1.0.33 - STILL COMPROMISED
@seung-ju/react-native-action-sheet 0.2.1 - STILL COMPROMISED
tcsp 2.0.2 - STILL COMPROMISED
web-types-lit 0.1.1 - STILL COMPROMISED
web-types-lit 0.1.1 - STILL COMPROMISED
Found 9 npm-reports/npm-latest-bad.txt packages STILL compromised!

See npm-reports/npm-latest-bad.txt for full listing.
Warning - Most people probably don't need to run this. It causes a lot of NPM traffic. Warning - There's a few packages this fails to download and check (likely bc's they are hosted outside of NPMjs.org)
ALT text details./is-npm-still-dangerous Reads the data/infected-pkgs.txt Downloads the latest package metadata for every known infected package Downloads the current latest package.tgz Uncompresses and scans the latest version using ./check-projects Depending upon the scan result ./is-npm-still-dangerous capacitor-voice-recorder-wav 6.0.3 - STILL COMPROMISED haufe-axera-api-client 0.0.2 - STILL COMPROMISED hyper-fullfacing 1.0.3 - STILL COMPROMISED @ifelsedeveloper/protocol-contracts-svm-idl 0.1.2 - STILL COMPROMISED my-saeed-lib 0.1.1 - STILL COMPROMISED quickswap-ads-list 1.0.33 - STILL COMPROMISED @seung-ju/react-native-action-sheet 0.2.1 - STILL COMPROMISED tcsp 2.0.2 - STILL COMPROMISED web-types-lit 0.1.1 - STILL COMPROMISED web-types-lit 0.1.1 - STILL COMPROMISED Found 9 npm-reports/npm-latest-bad.txt packages STILL compromised! See npm-reports/npm-latest-bad.txt for full listing. Warning - Most people probably don't need to run this. It causes a lot of NPM traffic. Warning - There's a few packages this fails to download and check (likely bc's they are hosted outside of NPMjs.org)
nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

I've spent the last few hours writing down my scripts for detecting this so you can use them!

I'm hitting on two or three ways to detect it and will be adding more.

Watching the attack running I can see developers all over the world still doing their morning `npm i` and getting owned 😭

Maybe let the node developers in your life know about this tool 👇🏿

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Updated my listing of Sha1-Hulud detection tools.

I now have found at least 12 other tools for detecting Sha1-Hulud compromise on your dev box and in infrastructure.

github.com/datapartyjs/walk-wi

Similar Sha1-Hulud 11/24/25 Detection Tools
Links to other projects provided with no warranty express or implied.

https://github.com/TimothyMeadows/sha1hulud-scanner
https://github.com/mottibec/sha1hulud-scanner
https://github.com/gensecaihq/Shai-Hulud-2.0-Detector
https://github.com/tprinty/sha1hulud-action-detector
https://github.com/da1z/amihulud
https://github.com/bobberg/sha1-hulud-folder-checker
https://github.com/servusdei2018/sha1-halud-scan
https://github.com/kevcooper/fremkit
https://github.com/ysskrishna/shai-hulud-detector
https://github.com/Cobenian/shai-hulud-detect
GitHub Scanners
https://github.com/ysskrishna/shai-hulud-detector
panther-labs/panther-analysis#1826
ALT text detailsSimilar Sha1-Hulud 11/24/25 Detection Tools Links to other projects provided with no warranty express or implied. https://github.com/TimothyMeadows/sha1hulud-scanner https://github.com/mottibec/sha1hulud-scanner https://github.com/gensecaihq/Shai-Hulud-2.0-Detector https://github.com/tprinty/sha1hulud-action-detector https://github.com/da1z/amihulud https://github.com/bobberg/sha1-hulud-folder-checker https://github.com/servusdei2018/sha1-halud-scan https://github.com/kevcooper/fremkit https://github.com/ysskrishna/shai-hulud-detector https://github.com/Cobenian/shai-hulud-detect GitHub Scanners https://github.com/ysskrishna/shai-hulud-detector panther-labs/panther-analysis#1826
nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

I've updated my suggestions to include links and info on how to get fine grained control over the scripts your projects run at compile time.

There's two fairly interesting community projects that seem to address this part of the problem and make it possible to disable most install scripts while keeping the ones your project actually requires.

github.com/datapartyjs/walk-wi

Steps to take
Turn on Multi-Factor Authentication (MFA / 2FA) immediately on your NPM & GitHub accounts (and all other key infra). Change and review passwords for cloud services you use.
You probably shouldn't run any npm install or npm update commands until NPM and GitHub have official mitigations in place.
Before doing anything else you probably should check for signs of comproise. This can be done manually or using this repo or other similar scanning tools. If you DO continue working from an infected machine you risk having your personal data stolen or destroyed by this worm.
After verifying that your system has not already been compromised you can likely safely work as normal but you should avoid upgrading or installing any different package versions. Its not fully clear at the time of posting if NPM is taking down infected packages we're still finding infected packages for download on NPM at this time.
Before installing a new version of a package, you can download a .tgz archive using the command npm pack <package-name>. This does not install the package. You can then uncompress the package and check it for signs of compromise.
Consider disabling install scripts
npm install --ignore-scripts - Ignore install scripts
npm config set ignore-scripts true - Ignore install scripts user wide
"Package install scripts vulnerability" - NPM blog post from 2016 explaining worm mitigations
Consider using a tool for fine grained script management
ALT text detailsSteps to take Turn on Multi-Factor Authentication (MFA / 2FA) immediately on your NPM & GitHub accounts (and all other key infra). Change and review passwords for cloud services you use. You probably shouldn't run any npm install or npm update commands until NPM and GitHub have official mitigations in place. Before doing anything else you probably should check for signs of comproise. This can be done manually or using this repo or other similar scanning tools. If you DO continue working from an infected machine you risk having your personal data stolen or destroyed by this worm. After verifying that your system has not already been compromised you can likely safely work as normal but you should avoid upgrading or installing any different package versions. Its not fully clear at the time of posting if NPM is taking down infected packages we're still finding infected packages for download on NPM at this time. Before installing a new version of a package, you can download a .tgz archive using the command npm pack <package-name>. This does not install the package. You can then uncompress the package and check it for signs of compromise. Consider disabling install scripts npm install --ignore-scripts - Ignore install scripts npm config set ignore-scripts true - Ignore install scripts user wide "Package install scripts vulnerability" - NPM blog post from 2016 explaining worm mitigations Consider using a tool for fine grained script management
nullagent's avatar
nullagent

@nullagent@partyon.xyz

There's an active nodejs supply chain attack going around.

From the looks of it many of these compromised packages have been mitigated but quite a few have not.

helixguard.ai/blog/malicious-s

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

These sorts of NPM worms have been around for a LONG time.

It's typically due a common practice of low 2fa opt-in on NPM accounts.

So be sure to setup NPM 2FA if you're a package maintainer do that asap!

A lesser known NPM capability is that you can disable install time scripts. This may break some packages but its worth a try to see if your projects can work with out any install scripts. 👇🏿

blog.npmjs.org/post/1417028810

Package install scripts vulnerability
Disclaimer: we had been told this vulnerability would be disclosed on Monday, not Friday, so this post is a little rushed and may be edited later.

As disclosed to us in January and formally discussed in CERT vulnerability note VU#319816, it is possible for a maliciously-written npm package, when installed, to execute a script that includes itself into a new package that it then publishes to the registry, and to other packages owned by that user.

npm cannot guarantee that packages available on the registry are safe. If you see malicious code on the registry, report it to support@npmjs.com and it will be taken down.

How to protect yourself
If you are installing a package that you do not trust, you can avoid this vulnerability by running

npm install --ignore-scripts

If you wish to never run scripts at install time, you can instead run

npm config set ignore-scripts true

Either or both of these steps will prevent you from spreading a worm at install time.

If you install a package that contains malicious code and then execute it (e.g. by require()ing it into your code) it could still perform malicious actions. You should not execute any software downloaded from the Internet if you do not trust it, including software downloaded from npm.
ALT text detailsPackage install scripts vulnerability Disclaimer: we had been told this vulnerability would be disclosed on Monday, not Friday, so this post is a little rushed and may be edited later. As disclosed to us in January and formally discussed in CERT vulnerability note VU#319816, it is possible for a maliciously-written npm package, when installed, to execute a script that includes itself into a new package that it then publishes to the registry, and to other packages owned by that user. npm cannot guarantee that packages available on the registry are safe. If you see malicious code on the registry, report it to support@npmjs.com and it will be taken down. How to protect yourself If you are installing a package that you do not trust, you can avoid this vulnerability by running npm install --ignore-scripts If you wish to never run scripts at install time, you can instead run npm config set ignore-scripts true Either or both of these steps will prevent you from spreading a worm at install time. If you install a package that contains malicious code and then execute it (e.g. by require()ing it into your code) it could still perform malicious actions. You should not execute any software downloaded from the Internet if you do not trust it, including software downloaded from npm.
nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Now that the acute phase is slowing there's a VERY important question...

What is actual fucking value does Microsoft (a trillion dollar company) owning GitHub & NPM bring at all?

This shit was an absolute corporate buyout disaster. How the ever living fuck has microsoft owned NPM for FIVE years and still not done proper MFA requirements for publishing packages on NPM.

How the actual fuck are well known vulnerable packages STILL being propagated by NPM.

A three panel meme

Top - "Hack the planet" shouts a man being forced into a police car

Center - A hacker in a ski mask at a computer works. "Some dune nerd"

Bottom - "Wait, no not like that!" -Microsoft
ALT text detailsA three panel meme Top - "Hack the planet" shouts a man being forced into a police car Center - A hacker in a ski mask at a computer works. "Some dune nerd" Bottom - "Wait, no not like that!" -Microsoft
nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

I spent more time searching for other Sha1-Hulud detection tools and found four more bringing it to 6 scanners (5 in nodejs).

Linked them all from my readme in case those work better for you.

Best way to beat a worm like this is to keep scanning and keep an eye out for the attacker to try and evade all of our tools.

By using more than one hopefully we make the attackers job harder to evade all of us.

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

GitHub has almost finished taking down the stolen data posted by the Sha1-Hulud npm/github worm. I only see about 400 repos remaining of the around 23k created by the worm.

This was the most visible evidence of the exploit, just because we can't clearly see the worm's uploads doesn't mean the worm is totally dead yet.

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

I spent more time searching for other Sha1-Hulud detection tools and found four more bringing it to 6 scanners (5 in nodejs).

Linked them all from my readme in case those work better for you.

Best way to beat a worm like this is to keep scanning and keep an eye out for the attacker to try and evade all of our tools.

By using more than one hopefully we make the attackers job harder to evade all of us.

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Just finished landing Exit Code support. So now if more scanners are made or one of the projects gets more features you can quickly switch to whichever makes the most sense for your use case!

I literally lost a ton of sleep on this volunteer incident response work so I'm going to go touch grass for a bit.

More hacks later tonight, still got some loose ends gnawing at me lol.

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

The fork of the CrowdStrike scanner introduced me to a really good idea, I should support the same exit code design so that our tools can work in tandem.

Maybe we detect different things or maybe one vs the other works in your environment.

So I made an issue to track this support:

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

I located a second tool for detecting Sha1-Hulud infections. Haven't looked at the details of how it works.

Some notes:

This one appears to have been released by CrowdStrike and was paywalled. Someone decided to modify and release it publicly so license is unknown.

But awesome to see I'm in the big leagues with CrowdStrike and I maybe the first clean open source release of a tool for this.

github.com/TimothyMeadows/sha1

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Checking back in on my GitHub query and the stolen data is STILL showing up on github.

I can tell github looks to be deleting the repos a -little- bit faster than they are created. There's still over 15k repos full of stolen credentials and PII available for public download.

I've also noticed some new behavior I hadn't seen before where the worm is now making commits look like Linus Torvalds wrote them. Clearly a delay tactic.

partyon.xyz/@nullagent/1156078

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

At the end of scanning for obvious compromise the `check-projects` script then builds a listing of all of your dependencies and all of the versions your project files mention.

You can find that info under `reports/`

I'm currently working on improving the `check-projects` script so that it will alert you if ANY of your package.json or package-lock.json mentions a known infected package.

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

First pass is super simple and just looks for the file names & package.json signature for signs of infection anywhere in the path you tell it to search.

If it sees anything fishy it tells you where and stops until you've read the alert.

Oh and this only uses bash, sed, awk, grep, curl, and jq. So no npm, node or other big supply chains 🥴

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Woot ok now that I have the dependency graph crawled I can just ship the listing of known bad NPM packages and just compare directly against that.

I updated the scanning script to alert if you have -any- version of an infected package.

You're gonna want to be very careful if you're not infected but have one of these dependencies present.

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

At the end of scanning for obvious compromise the `check-projects` script then builds a listing of all of your dependencies and all of the versions your project files mention.

You can find that info under `reports/`

I'm currently working on improving the `check-projects` script so that it will alert you if ANY of your package.json or package-lock.json mentions a known infected package.

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

First pass is super simple and just looks for the file names & package.json signature for signs of infection anywhere in the path you tell it to search.

If it sees anything fishy it tells you where and stops until you've read the alert.

Oh and this only uses bash, sed, awk, grep, curl, and jq. So no npm, node or other big supply chains 🥴

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

I'm quickly finding a mix of packages which were compromised, some were months ago and had the bad versions taken down.

However at the same time I'm noticing packages like the one below that were -just- hacked 19 hours ago and still have not been taken down yet!

With how this worm works its a bit of a pencils down moment... you probably should check your packages right now.

npmjs.com/package/capacitor-vo

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

I've spent the last few hours writing down my scripts for detecting this so you can use them!

I'm hitting on two or three ways to detect it and will be adding more.

Watching the attack running I can see developers all over the world still doing their morning `npm i` and getting owned 😭

Maybe let the node developers in your life know about this tool 👇🏿

github.com/datapartyjs/walk-wi

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Ok I've downloaded some of the compromised packages and you can search your already downloaded node modules for possibly infected packages using this command:

find ./node_modules -type f -name "bun_environment.js"

You can check your user level node cache using:

find ~/.npm -type f -name "bun_environment.js"

Still sizing this one up but if you get any hits check and see if they are big files (around 10MB) and if so you're likely infected.

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

Taking a second to understand the attack rate. I constructed this query below which shows you essentially an up to date listing of developers/code that's been compromised.

Once your box is infected and PII data has been found the worm then uses your github credentials to upload that content so ANYONE can now steal your credentials.

I'm finding multiple repos being popped every minute. This is an extremely active attack right now.

github.com/search?q=%22Sha1-Hu

nullagent's avatar
nullagent

@nullagent@partyon.xyz · Reply to nullagent's post

I'm quickly finding a mix of packages which were compromised, some were months ago and had the bad versions taken down.

However at the same time I'm noticing packages like the one below that were -just- hacked 19 hours ago and still have not been taken down yet!

With how this worm works its a bit of a pencils down moment... you probably should check your packages right now.

npmjs.com/package/capacitor-vo

nullagent's avatar
nullagent

@nullagent@partyon.xyz

There's an active nodejs supply chain attack going around.

From the looks of it many of these compromised packages have been mitigated but quite a few have not.

helixguard.ai/blog/malicious-s

Soatok Dreamseeker's avatar
Soatok Dreamseeker

@soatok@furry.engineer

Moving Beyond the NPM elliptic Package

If you're in a hurry, head on over to soatok/elliptic-to-noble and follow the instructions in the README in order to remove the elliptic package from your project and all dependencies in node_modules. Art: CMYKat Why replace the elliptic package? Yesterday, the Trail of Bits blog published an intern's post about finding cryptographic bugs in the elliptic library (a Javascript package on NPM) by using the Wycheproof.

soatok.blog/2025/11/19/moving-

Soatok Dreamseeker's avatar
Soatok Dreamseeker

@soatok@furry.engineer

Moving Beyond the NPM elliptic Package

If you're in a hurry, head on over to soatok/elliptic-to-noble and follow the instructions in the README in order to remove the elliptic package from your project and all dependencies in node_modules. Art: CMYKat Why replace the elliptic package? Yesterday, the Trail of Bits blog published an intern's post about finding cryptographic bugs in the elliptic library (a Javascript package on NPM) by using the Wycheproof.

soatok.blog/2025/11/19/moving-

Karsten Schmidt's avatar
Karsten Schmidt

@toxi@mastodon.thi.ng

question regarding the dreaded NPM or similar malware to harvest auth tokens:

To avoid a potential infection leading to harvesting the token usually stored in `~/.npmrc`, I changed that file's content to:

`//registry.npmjs.org/:_authToken=${NPM_TOKEN}`

...and now only keep an ephemeral `NPM_TOKEN` env var when I need it. Are there any better approaches? What are you doing as prophylaxis?

Vladimir Leonidovich's avatar
Vladimir Leonidovich

@vladimirleonidovich@mastodon.social

Посоветуйте приложение для , куда я смогу сохранять токены доступа к разными сервисам и API: , , и другие.
Пробовал искать, но дельного не нашёл.

Karsten Schmidt's avatar
Karsten Schmidt

@toxi@mastodon.thi.ng · Reply to Karsten Schmidt's post

An update: After several failed publish attempts, more searching, (re)reading and experimenting for the past 4 hours, I've now figured out a solution using granular access tokens... But to summarize & document the issues, in case someone else encounters the same pain points:

1) There seems to be a new incompatibility between the NPM auth changes and running `yarn npm publish --access public`. After working successfully for the past 8 years, that command now gives me 404, even after re-authenticating. It just doesn't seem to pick up the auth token configured in `$HOME/.npmrc`. As result I've now switched all my publish commands to just be `npm publish --access public`. That seems to work!

2) The wording about the 50 package limit on the NPM auth token docs is very confusing: "Each token can access up to 50 organizations, and up to either 50 packages, 50 scopes, or a combination of 50 packages and scopes." As written, this reads like these limits are omnipresent for each token, but in fact one can also create tokens which can access ALL packages under your control. The 50 limit only seems to apply when creating token which is only allowed a subset...

Summa summarum, it is after all (updates to thi.ng/geom, bug fixes for thi.ng/args) and I can now proceed to enjoy the start of the Glühwein season on this cold Friday night... 🎉

Karsten Schmidt's avatar
Karsten Schmidt

@toxi@mastodon.thi.ng

Okay, it seems classic NPM tokens already stopped working and so it's IMPOSSIBLE for me to release any new versions of my 210 projects/packages until they have implemented a solution which:

1) Doesn't require to manually setup a Trusted Publishing config for *every single package* or
2) They're lifting the arbitrary 50 packages per token limit for their new "granular" tokens (in addition to them already being severely time limited)

The current combined effect of these two restrictions means I cannot do automated multi-package releases from my monorepo, using a tool which handles changelog generation, version bumps and topological sorting of releases.

It's bloody infuriating! NPM has ignored looming security issues for a decade. Now they're rushing some halfbaked no-solution with several glaring issues, all within a few weeks notice and then not even sticking to their timeline. Classic tokens were supposed to stop working in November only...

Karsten Schmidt's avatar
Karsten Schmidt

@toxi@mastodon.thi.ng · Reply to Karsten Schmidt's post

So to make it all even "better": To use Trusted Publishing, one also has to manually setup a GitHub Actions integration on npmjs.org for every single package individually! This is just mind boggling and infeasible and means I'd have to manually fill in a form 200+ times (for that many packages) before I could even properly test this new publishing workflow.

Other people who're maintaining thousands of packages (e.g. DefinitilyTyped, Fontsource) have chimed in here too: github.com/orgs/community/disc

Let's hope this will be addressed!

Karsten Schmidt's avatar
Karsten Schmidt

@toxi@mastodon.thi.ng

So am I understanding this correctly that the upcoming NPM authentication and token changes mean our only publishing workflow options henceforth are either switching to OICD Trusted Publishing[1] via GitHub Actions or using granular access tokens. The problem with the former is that I wanted to migrate my projects to Codeberg soon (which isn't supported). The problem with the latter is that granular tokens are unsuitable for publishing packages from a large monorepo, since these tokens are limited to 50 packages only (in addition to time limits)[2].

My thi.ng/umbrella repo contains 210 packages, so in order to publish them (sometimes all of them will need to be updated) I'd have to first generate multiple tokens and then also keep track how many times each token has been used. This adds a lot of extra work and complexity to my monorepo publishing tool (thi.ng/monopub). I understand the need for improved NPM security, but as so often, these changes are just poorly thought through (IMO) and continuously add new workloads and complexity on maintainers...

[1] docs.npmjs.com/trusted-publish
[2] docs.npmjs.com/about-access-to

ansuz / ऐरन's avatar
ansuz / ऐरन

@ansuz@social.cryptography.dog

The folks at npm sent out an email indicating that they were changing their security policies relating to the use of 2FA.

The information given was pretty vague, but they linked to a few resources for further reading. These included:

1. a gh.io link - which does not look authoritative at all

2. a random discussion on github, not even one on an npm-operated org

3. npm's generic support page

...and they wonder why people fall for phishing schemes :blobcat_thisisfine:

ansuz / ऐरन's avatar
ansuz / ऐरन

@ansuz@social.cryptography.dog

The folks at npm sent out an email indicating that they were changing their security policies relating to the use of 2FA.

The information given was pretty vague, but they linked to a few resources for further reading. These included:

1. a gh.io link - which does not look authoritative at all

2. a random discussion on github, not even one on an npm-operated org

3. npm's generic support page

...and they wonder why people fall for phishing schemes :blobcat_thisisfine:

Patrick Wu :neocat_flag_bi:'s avatar
Patrick Wu :neocat_flag_bi:

@patrick@hatoya.cafe

One Open-source Project Daily

The NPM drinking game recreated and cli-ified with Deno

https://github.com/ninest/drink-if-exists

Patrick Wu :neocat_flag_bi:'s avatar
Patrick Wu :neocat_flag_bi:

@patrick@hatoya.cafe

One Open-source Project Daily

The NPM drinking game recreated and cli-ified with Deno

https://github.com/ninest/drink-if-exists

Kat Marchán 🐈's avatar
Kat Marchán 🐈

@zkat@toot.cat

lmao now legitimate security emails from NPM are considered phishing. What a shitshow.

screenshot of an email that clearly says it's from support@npmjs.com, a legitimate email address belonging to the NPM support team. Fastmail has flagged it as suspicious, and that it might be a phishing attempt. The email seems to be about some "security improvements".
ALT text detailsscreenshot of an email that clearly says it's from support@npmjs.com, a legitimate email address belonging to the NPM support team. Fastmail has flagged it as suspicious, and that it might be a phishing attempt. The email seems to be about some "security improvements".
Lovell Fuller's avatar
Lovell Fuller

@lovell@mastodon.social

🔒 If you publish packages to the npm registry and haven't already seen its new Trusted Publisher feature, please do take a look at docs.npmjs.com/trusted-publish

🎟️ It uses short-lived OIDC tokens to allow CI-based automation of signed publish-with-provenance.

📈 According to github.com/sxzz/npm-top-proven I maintain 6 of the top 50 packages that use this feature, and those 6 packages combined have over 600 million downloads each month!

Lovell Fuller's avatar
Lovell Fuller

@lovell@mastodon.social

🔒 If you publish packages to the npm registry and haven't already seen its new Trusted Publisher feature, please do take a look at docs.npmjs.com/trusted-publish

🎟️ It uses short-lived OIDC tokens to allow CI-based automation of signed publish-with-provenance.

📈 According to github.com/sxzz/npm-top-proven I maintain 6 of the top 50 packages that use this feature, and those 6 packages combined have over 600 million downloads each month!

Waseem's avatar
Waseem

@iamwaseem@mastodon.social

It's been some weeks with npm exploits. But there is a fix, Deno's limited permissions can help here.
deno.com/blog/deno-protects-np

Waseem's avatar
Waseem

@iamwaseem@mastodon.social

It's been some weeks with npm exploits. But there is a fix, Deno's limited permissions can help here.
deno.com/blog/deno-protects-np

Waseem's avatar
Waseem

@iamwaseem@mastodon.social

It's been some weeks with npm exploits. But there is a fix, Deno's limited permissions can help here.
deno.com/blog/deno-protects-np

Daemon Silverstein's avatar
Daemon Silverstein

@dsilverz@calckey.world

from .js ended up in the hands of Microsoft.

from ended up in the hands of a nazi libertarian.

It feels like
and are being attacked on a daily basis.

Do anyone have information regarding
from , is it also compromised? As far as I know, PyPi stopped working with pip search ("Use the browser") and the website needs JS to function (because it uses some PoW browser checking), so using Lynx or elinks as a sysadmin on a terminal-only machine in order to search for Python packages have been a no-no. Wonder how much it's due to similar phenomenon going on with Ruby and Node.js ecosystems.

Kat Marchán 🐈's avatar
Kat Marchán 🐈

@zkat@toot.cat

cross-posting my little rant about stuff here:

Random NPM thoughts of the day:

  1. The primary NPM registry should be obsoleted entirely ASAP
  2. JSR does not do anywhere near as much as it should, and it's probably too late to fix.
  3. A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
  4. All packages MUST be ESM (JSR ok here)
  5. MUST include docstrings on all publicly-reachable interfaces.
  6. MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
  7. MUST have a non-trivial README.
  8. MUST be tied to a PUBLIC repo.
  9. MUST NOT have install scripts (yeah sorry, the fight's over)
  10. 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.
  11. 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:

  1. Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
  2. Autogenerated API docs.
  3. 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.
  4. Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
  5. Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
  6. 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?]
  7. 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.

Tane Piper's avatar
Tane Piper

@tanepiper@tane.codes

Oh no, not again... a meditation on supply chain attacks

tane.dev/2025/09/oh-no-not-aga

Tane Piper's avatar
Tane Piper

@tanepiper@tane.codes

Oh no, not again... a meditation on supply chain attacks

tane.dev/2025/09/oh-no-not-aga

derekheld's avatar
derekheld

@derekheld@infosec.exchange

A bunch of packages published by qix in NPM just got backdoored it looks like. Obfuscated code was added like two hours ago.

Emelia 👸🏻's avatar
Emelia 👸🏻

@thisismissem@hachyderm.io · Reply to Emelia 👸🏻's post

Also, npm now supports trusted publishing: docs.npmjs.com/trusted-publish

This means you don't need a static token in your CI/CD configuration anymore.

Emelia 👸🏻's avatar
Emelia 👸🏻

@thisismissem@hachyderm.io

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.

derekheld's avatar
derekheld

@derekheld@infosec.exchange

A bunch of packages published by qix in NPM just got backdoored it looks like. Obfuscated code was added like two hours ago.

Ben Hardill's avatar
Ben Hardill

@ben@hardill.me.uk

Hmm, most of my GitHub CI jobs are failing because it appears NPM have added rate limiting.

Remind me again, who owns both NPM and GitHub these days?

Ben Hardill's avatar
Ben Hardill

@ben@hardill.me.uk

Hmm, most of my GitHub CI jobs are failing because it appears NPM have added rate limiting.

Remind me again, who owns both NPM and GitHub these days?

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

洪 民憙 (Hong Minhee) :nonbinary:'s avatar
洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social

Introducing !

A simple, cross-runtime email library that works seamlessly on , .js, , and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.

Switch between , , without changing your code. Available on & !

https://upyo.org/

BastilleBSD :freebsd:'s avatar
BastilleBSD :freebsd:

@BastilleBSD@fosstodon.org

Are npm packages and dependencies an unmitigated disaster, or is it just me?

Alex0007's avatar
Alex0007

@Alex0007@mastodon.social

It's crazy that `graphql-depth-limit` (with its Git repository removed and not being updated for 8 years) has 750k weekly downloads, while the actual `@graphile/depth-limit` library (updated, typed, from a GraphQL maintainer) has only 400 downloads.

lil5 :golang: 🚲 🇳🇱's avatar
lil5 :golang: 🚲 🇳🇱

@lil5@social.linux.pizza

OptionVoters
Deno4 (57%)
Bun3 (43%)
skry's avatar
skry

@skry@mastodon.social

“slopsquatting, a new term for a surprisingly effective type of software supply chain attack that emerges when LLMs “hallucinate” package names that don’t actually exist. If you’ve ever seen an AI recommend a package and thought, “Wait, is that real?”—you’ve already encountered the foundation of the problem.

And now attackers are catching on.”

The Rise of Slopsquatting: How Hallucinations Are Fueling... socket.dev/blog/slopsquatting-

Edit: more info: bleepingcomputer.com/news/secu

skry's avatar
skry

@skry@mastodon.social

“slopsquatting, a new term for a surprisingly effective type of software supply chain attack that emerges when LLMs “hallucinate” package names that don’t actually exist. If you’ve ever seen an AI recommend a package and thought, “Wait, is that real?”—you’ve already encountered the foundation of the problem.

And now attackers are catching on.”

The Rise of Slopsquatting: How Hallucinations Are Fueling... socket.dev/blog/slopsquatting-

Edit: more info: bleepingcomputer.com/news/secu

Richie Khoo's avatar
Richie Khoo

@richiekhoo@hachyderm.io

Package Manager for Markdown

I'm working on a project that is intended to encourage folk to make markdown text files which can be bundled together in different bundles of text files using a package manager.

Question for coders; Which package manager would you suggest I use?

Main criterias (in order) are:

1. Easy for someone with basic command line skills to edit the file and update version numbers and add additional packages.

2. All being equal, more commonly and easy to setup is preferred.



Maho 🦝🍻's avatar
Maho 🦝🍻

@mapache@hachyderm.io

Rust cargo is the new npm-packages lol

Chee Aun 🤔's avatar
Chee Aun 🤔

@cheeaun@mastodon.social

Huh, Runkit has been gone for few months and npm pages are still linking to it github.com/orgs/community/disc

The forum is also filled with reports and spam discuss.runkit.com/ 😥

Deno's avatar
Deno

@deno_land@fosstodon.org

Are you still using npm transpile services like esm.sh and unpkg.com?
❌ dependency deduplication
❌ install hooks and native add-ons
❌ loading data files

Here's why we recommend importing npm packages natively via npm specifiers 👇

deno.com/blog/not-using-npm-sp

Inautilo's avatar
Inautilo

@inautilo@mastodon.social


SQL Noir · A game to learn SQL by solving crimes ilo.im/162ciw

_____

Inautilo's avatar
Inautilo

@inautilo@mastodon.social


SQL Noir · A game to learn SQL by solving crimes ilo.im/162ciw

_____

Emelia 👸🏻's avatar
Emelia 👸🏻

@thisismissem@hachyderm.io

Why does the npm user or organisation on npm have 64,788 packages?

Screenshot of the user or organisation profile for npm on the npm registry showing 64,788 packages all from different authors.
ALT text detailsScreenshot of the user or organisation profile for npm on the npm registry showing 64,788 packages all from different authors.
Deno's avatar
Deno

@deno_land@fosstodon.org

Are you still using npm transpile services like esm.sh and unpkg.com?
❌ dependency deduplication
❌ install hooks and native add-ons
❌ loading data files

Here's why we recommend importing npm packages natively via npm specifiers 👇

deno.com/blog/not-using-npm-sp

⚯ Michel de Cryptadamus ⚯'s avatar
⚯ Michel de Cryptadamus ⚯

@cryptadamist@universeodon.com · Reply to @reiver ⊼ (Charles) :batman:'s post

@reiver i built on to make a customizable feed algorithm that is pretty much how i interact with these days. it's available as an package.

here's the demo app: github.com/michelcrypt4d4mus/f

this is what the demo app looks like:

screenshot of fedialgo in action
ALT text detailsscreenshot of fedialgo in action
⚯ Michel de Cryptadamus ⚯'s avatar
⚯ Michel de Cryptadamus ⚯

@cryptadamist@universeodon.com · Reply to @reiver ⊼ (Charles) :batman:'s post

@reiver i built on to make a customizable feed algorithm that is pretty much how i interact with these days. it's available as an package.

here's the demo app: github.com/michelcrypt4d4mus/f

this is what the demo app looks like:

screenshot of fedialgo in action
ALT text detailsscreenshot of fedialgo in action
Szymon Standarski's avatar
Szymon Standarski

@standarski@mastodon.social

🚀 npm install vs. npm ci

• npm install: 📦 Installs dependencies from package.json, updates package-lock.json if needed. Flexible but slower.
• npm ci: ⚡ Clean, fast install based only on package-lock.json. Reproducible builds, perfect for CI/CD.

💡Tip: Use npm ci for consistent, reliable deployments! ✅

Szymon Standarski's avatar
Szymon Standarski

@standarski@mastodon.social

🚀 npm install vs. npm ci

• npm install: 📦 Installs dependencies from package.json, updates package-lock.json if needed. Flexible but slower.
• npm ci: ⚡ Clean, fast install based only on package-lock.json. Reproducible builds, perfect for CI/CD.

💡Tip: Use npm ci for consistent, reliable deployments! ✅

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 🤝️ Nuxt.js

docs.deno.com/examples/nuxt_tu

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 🤝️ Nuxt.js

docs.deno.com/examples/nuxt_tu

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 🤝️ Nuxt.js

docs.deno.com/examples/nuxt_tu

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 2.1.5 just landed —

▸ new QUIC API
▸ improved Discord.js compatibility
▸ better tasks support in workspaces

github.com/denoland/deno/relea

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 2.1.5 just landed —

▸ new QUIC API
▸ improved Discord.js compatibility
▸ better tasks support in workspaces

github.com/denoland/deno/relea

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 2.1.5 just landed —

▸ new QUIC API
▸ improved Discord.js compatibility
▸ better tasks support in workspaces

github.com/denoland/deno/relea

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 2.1.5 just landed —

▸ new QUIC API
▸ improved Discord.js compatibility
▸ better tasks support in workspaces

github.com/denoland/deno/relea

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno is committed to web standards - that's why we co-founded WinterCG two years ago. Today marks the next step in that journey: WinterCG moves to Ecma International as technical comittee 55 (TC55).

Goodbye WinterCG, welcome WinterTC!

deno.com/blog/wintertc

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno is committed to web standards - that's why we co-founded WinterCG two years ago. Today marks the next step in that journey: WinterCG moves to Ecma International as technical comittee 55 (TC55).

Goodbye WinterCG, welcome WinterTC!

deno.com/blog/wintertc

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 2.1.5 just landed —

▸ new QUIC API
▸ improved Discord.js compatibility
▸ better tasks support in workspaces

github.com/denoland/deno/relea

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno is committed to web standards - that's why we co-founded WinterCG two years ago. Today marks the next step in that journey: WinterCG moves to Ecma International as technical comittee 55 (TC55).

Goodbye WinterCG, welcome WinterTC!

deno.com/blog/wintertc

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno is committed to web standards - that's why we co-founded WinterCG two years ago. Today marks the next step in that journey: WinterCG moves to Ecma International as technical comittee 55 (TC55).

Goodbye WinterCG, welcome WinterTC!

deno.com/blog/wintertc

Deno's avatar
Deno

@deno_land@fosstodon.org

Thank you for your support in helping us reach 100,000 GitHub stars! ⭐️

github.com/denoland/deno

Deno's avatar
Deno

@deno_land@fosstodon.org

Thank you for your support in helping us reach 100,000 GitHub stars! ⭐️

github.com/denoland/deno

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno can now finally be installed through npm!

npm install -g deno

npx deno eval -p 1+2

npmjs.com/package/deno

tea 🌺's avatar
tea 🌺

@thomasreggi@indieweb.social

Would love thoughts and feedback on my Future / deferred promise library:

npmjs.com/package/@reggi/futur

Be kind ❤️

Deno's avatar
Deno

@deno_land@fosstodon.org

Easily check for outdated dependencies with `deno outdated` 👇️

docs.deno.com/runtime/referenc

Deno outdated will check for outdated dependencies.
ALT text detailsDeno outdated will check for outdated dependencies.
Deno's avatar
Deno

@deno_land@fosstodon.org

this wren wants to remind you that Deno permission flags have shorthands

deno.com/blog/v1.46#short-hand

deno permission flags have shorthands
ALT text detailsdeno permission flags have shorthands
Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 2.1 is out 🎉️
✈️️ first class Wasm support
🌳️ Long Term Support branch
⭐️ Improved dependency management
and much more!

deno.com/blog/v2.1

Angelika Cathor's avatar
Angelika Cathor

@angelikatyborska@mas.to

I wrote my thoughts on how to decide what's a regular dependency and what's a dev dependency in a JavaScript app (not library). It's surprisingly unclear... angelika.me/2024/11/11/depende

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno is a JavaScript package manager with more flexibility:
📦️ npm and JSR
🛠️️ package.json and deno.json
👟️ fast

deno.com/blog/your-new-js-pack

Deno's avatar
Deno

@deno_land@fosstodon.org

The 🦕️ is out of the bag...

youtube.com/watch?v=pcC4Dr6Wj2

Deno's avatar
Deno

@deno_land@fosstodon.org

Curious about how the JSR logo and website design came together? 🤔️

Here's a 👀️ into our design process.

deno.com/blog/designing-jsr

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno 1.46 is not only the last 1.x release, but also one of the biggest:
- Simpler CLI
- Multi-threaded web servers
- HTML, CSS, YAML support in `deno fmt`
- Better Node/npm compat (support for playwright, google-cloud, etc.)
and much more 👇️

deno.com/blog/v1.46

Deno's avatar
Deno

@deno_land@fosstodon.org

Deno is known for its HTTP imports, but we've found it's insufficient for larger projects. This post explains the situation and how we've improved it.

deno.com/blog/http-imports

Deno's avatar
Deno

@deno_land@fosstodon.org

std/data-structures, common data structures including red-black trees and binary heaps, is now stabilized at v1 on JSR

jsr.io/@std/data-structures

Fedify: ActivityPub server framework's avatar
Fedify: ActivityPub server framework

@fedify@hollo.social

The fedify command is now available on ! You can install it using the following command:

npm install -g @fedify/cli

Or if you use :

bun install -g @fedify/cli

https://www.npmjs.com/package/@fedify/cli

NosirrahSec 🏴‍☠️'s avatar
NosirrahSec 🏴‍☠️

@NosirrahSec@infosec.exchange

CVE-2023-49210 - node-openssl, this sounds like a malicious node package and it's just now popping in Defender Vulnerability Management inventories.

Did we miss some big story about this or is this just a case of the NVD backlog catching up and thus downstream ingestion of that information is just now making it to the masses?

I figured a malicious OSS package/update getting put into the ecosystem would be a hot article after the debacle.

Anyone got better info than I do after doing some hunting? All I have are the initial detections from 3rd parties in November of 2023.