We also caught this right away at Socket,

https://socket.dev/blog/npm-author-qix-compromised-in-major-...

While it sucks that this happened, the good thing is that the ecosystem mobilized quickly. I think these sorts of incidents really show why package scanning is essential for securing open source package repositories.

Just want to agree with everyone who is thanking you for owning up (and so quickly). Got phished once while drunk in college (a long time ago), could have been anyone. NPM being slowish to get back to you is a bit surprising, though. Seems like that would only make attacks more lucrative.

Hey, no problem, man. You do a lot for the community, and it's not all your fault. We learn from our mistakes. I was thinking of having a public fake profile to avoid this type of attack, but I'm not sure how it would work on the git tracking capabilities. Probably keeo it only internally for you&NPM ( the real one ) and have some fake ones open for public but not sure, just an obfuscated idea. Thanks for taking the responsibility and working in fixing ASAP. God bless you.

Tbh, it's not your fault per se; everybody can fall for phishing emails. The issue, IMO, lies with npmjs which publishes to everyone all at the same time. A delayed publish that allows parties like Aikido and co to scan for suspicious package uploads first (e.g. big changes in patch releases, obfuscated code, code that intercepts HTTP calls, etc), and a direct flagging system at NPM and / or Github would already be an improvement.

Thanks for sounding the alarm. I've sent an abuse email to porkbun to hopefully get the domain taken down.

Yo, someone at npm needs to unpublish simple-swizzle@0.2.3 IMMEDIATELY. It’s still actively compromised.

Thank you for your service.

Please take care and see this as things that happen and not your own personal failure.

Hey, you're doing an exemplary response, transparent and fast, in what must be a very stressful situation!

I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA:

TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enough.

I don't understand how most of the anti-phishing advice focuses on that, it's useless to borderline counter-productive.

What really helps against phishing :

1. NEVER EVER login from an email link. EVER. There are enough legit and phishing emails asking you to do this that it's basically impossible to tell one from the other. The only way to win is to not try.

2. U2F/Webauthn key as second factor is phishing-proof. TOTP is not.

That is all there is. Any other method, any other "indicator" helps but is error-prone, which means someone somewhere will get phished eventually. Particularly if stressed, tired, or in a hurry. It just happened to be you this time.

Good luck and well done again on the response!

Absolutely best response here.

Folks from multi-billion dollar companies with multimillion dollar packages should learn a few things from this response.

Could happen to any of us. Thanks for reacting so quickly!!

Hey, new dev here. Sorry if this is a common knowledge and I am asking a stupid question. How does you getting phished affect these NPM packages? aren't these handled by NPM or the developers of them?

The fact that NPMs entire ecosystem relies on this not happening regularly is very scary.

I’m extremely security conscious and that phishing email could have easily gotten me. All it takes is one slip up. Tired, stressed, distracted. Bokm, compromised

Thank you for the swift and candid response, this has to suck. :/

> The author appears to have deleted most of the compromised package before losing access to his account. At the time of writing, the package simple-swizzle is still compromised.

Is this quote from TFA incorrect, since npm hasn’t yanked anything yet?

Didn't your password manager notice that npmjs dot help was not a legit domain and avoid auto-filling there?

Could happen to anyone, many thanks for addressing this quickly.

I hate that kind of email when sent out legitimately. Google does this crap all the time pretty much conditioning their customers to click those links. And if you're really lucky it's from some subdomain they never bothered advertising as legit.

Great of you to own up to it.

Thank you for being quick and upfront about this!

I am not very sophisticated npm user on MacOS, but I installed bunch of packages for Claude Code development. How do we check if computer has a problem?

Do we just run:

npm list -g #for global installs

npm list #for local installs

And check if any packages appear that are on the above list?

Thanks!

The 2FA/TOTP security theater was partly to blame for this.

insanely well-crafted. i mean, it's something bad that happened but one must recognise the wit of this attack.

> Made the mistake of clicking the link instead of going directly to the site like I normally would (since I was mobile).

Does anyone know how this attack works? Is it a CSRF against npmjs.com?

Thanks for leaving a transparent response with what happened, how you responded, what you're doing next, and concisely taking accountability Great work!

Happens to the best of people. Appreciate you’re fast and open response.

You're doing what you can, it's not easy. Thanks for handling this so well.

Thanks for your response. But this does call for preventing a single point of failure for security.

So by "Just NPM is affected" does that mean yarn is unaffected?

What did the phishing email say that made you click and login?

Insanely well crafted phishing, godspeed man.

I'm sorry that you're having to go through this. Good luck sorting out your account access.

I actually got hit by something that sounds very similar back in July. I was saved by my DNS settings where "npNjs dot com" wound up on a blocklist. I might be paranoid, but it felt targeted and was of a higher level of believability than I'd seen before.

I also more recently received another email asking for an academic interview about "understanding why popular packages wouldn't have been published in a while" that felt like elicitation or an attempt to get publishing access.

Sadly both of the original emails are now deleted so I don't have the exact details anymore, but stay safe out there everyone.

Thank god I misspelled "npm run strat"! Might have been owned.

`error-ex` 1.3.3, already removed from npm https://github.com/Qix-/node-error-ex/issues/17

Hang in there buddy. These things happen.

we're only human mate, great job responding to it!

thanks for your efforts!

maybe you should work with feross to make a website-api that simply gives you a "true/false" on "can I safely update my dependencies right now" that gives an outofband way to mark the current or all versions thereof, of compromised packages.

man. anyone and everyone can get fished in a targeted attack. good luck on the cleanup and thanks for being forward about it.

want to stress everyone it can happen to. no one has perfect opsec or tradecraft as a 1 man show. its simply not possible. only luck gets one through and that often enough runs out.

mistakes happen. owning them doesn't always happen, so well done.

phishing is too easy. so easy that I don't think the completely unchecked growth of ecosystems like NPM can continue. metastasis is not healthy. there are too many maintainers writing too many packages that too many others rely on.

Sorry to be dumb, but can you expand a bit on "2FA reset email..." so the rest of us know what not to do?

Not your fault. Thanks for posting and being proactive about fixing the problem. It could happen to anyone.

And because it could happen to anyone that we should be doing a better job using AI models for defense. If ordinary people reading a link target URL can see it as suspicious, a model probably can too. We should be plumbing all our emails through privacy-preserving models to detect things like this. The old family of vulnerability scanners isn't working.

I'm a little confused on one of the excerpts from your article.

> Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3

As far as I've always understood, the lockfile always specifies one single, locked version for each dependency, and even provides the URL to the tarball of that version. You can define "x version or newer" in the package.json file, but if it updates to a new patch version it's updating the lockfile with it. The npm docs suggest this is the case as well: https://arc.net/l/quote/cdigautx

And with that, packages usually shouldn't be getting updated in your CI pipeline.

Am I mistaken on how npm(/yarn/pnpm) lockfiles work?

We should be displaying hashes in a color scheme determined by the hash (foreground/background colors for each character determined by a hash of the hash, salted by that character's index, adjusted to ensure sufficient contrast).

That way it's much harder to make one hash look like another.

Can you attribute this technique to a specific group?

That moment where you respect the hacker. Still we are encroaching on dark times.

> This is a brilliant piece of social engineering baked right into the code. It's designed to specifically defeat the common security habit ...

I don't agree that the exuberance over the brilliance of this attack is warranted if you give this a moment's thought. The web has been fighting lookalike attacks for decades. This is just a more dynamic version of the same.

To be honest, this whole post has the ring of AI writing, not careful analysis.

For a package with thousands of downloads a week, does the publishing pace need to be so fast? New version could be uploaded to NPM, then perhaps a notification email to the maintainer saying it will go live on XX date and click here to cancel?

A lot of these security measures have trade offs, particularly when we start looking at heuristics or attestation-like controls.

These can exclude a lot of common systems and software, including automations. If your heuristic is quite naive like "is using Linux" or "is using Firefox" or "has an IP not in the US" you run into huge issues. These sound stupid, because they are, but they're actually pretty common across a lot of software.

Similar thing with 2FA. Sms isn't very secure, email primes you to phishing, TOTP is good... but it needs to be open standard otherwise we're just doing the "exclude users" thing again. TOTP is still phishable, though. Only hardware attestation isn't, but that's a huge red flag and I don't think NPM could do that.

Interesting. According to https://www.wiz.io/blog/s1ngularity-supply-chain-attack the initial entry point was a "flawed GitHub Actions workflow that allowed code injection through unsanitized pull request titles" — which was detected and mitigated on August 29.

That was more than ten days ago, and yet major packages were compromised yesterday. How?

> Somebody has to just implement the standard security measures that prevents these compromises.

I don't disagree, but this sentence is doing a lot of heavy lifting. See also "draw the rest of the owl".

> Somebody has to just implement the standard security measures that prevents these compromises.

It's not that simple. You can implement the most stringent security measures, and ultimately a human error will compromise the system. A secure system doesn't exist because humans are the weakest link.

So while we can probably improve some of the processes within npm, phishing attacks like the ones used in this case will always be a vulnerability.

You're right that AI tools will make these attacks more common. That phishing email was indistinguishable from the real thing. But AI tools can also be used to scan and detect such sophisticated attacks. We can't expect to fight bad actors with superhuman tools at their disposal without using superhuman tools ourselves. Fighting fire with fire is the only reasonable strategy.

People focus on attacking windows because there are more windows users. What if I told you the world now has a lot more people involved in programming with JavaScript and Python?

You’re right, this will only get a lot worse.

NPM is owned by GitHub and therefore Microsoft, who is too busy putting in Copilot into apps that have 0 reason to have any form of generative AI in them

For packages which have multiple maintainers, they should at least offer the option to require another maintainer to approve each publish.

Identical, highly obfuscated (and thus suspicious looking) payload was inserted into 22+ packages from the same author (many dormant for a while) simultaneously and published.

What kind of crazy AI could possible have noticed that on the NPM side?

This is frustrating as someone that has built/published apps and extensions to other software providers for years and must wait days or weeks for a release to be approved while it's scanned and analyzed.

For all the security wares that MS and GitHub sell, NPM has seen practically no investment over the years (e.g. just go review the NPM security page... oh, wait, where?).

I blame the prevalence of package mangers in the first place. Never liked em, just for this reason. Things were fine before they became mainstream. Another annoying reason is package files that are set to grab the latest version, randomly breaking your environment. This isn't just npm of course, I hate them all equally.

Why would NPM do anything about it? NPM has been a great source of distributing malware for like a decade now, and none of you have stopped using it.

Why in the world would they NEED to stop? It apparently doesn't harm their "business"

Sorry, I am unfamiliar with ripgrep. Is this simply scanning for the string `_0x112fa8`? Could we do the same thing with normal grep -r?

Asking people to run random install scripts just feels very out of place given the context.

Try the same recursive grep on ~/.npm to see if you have it cached too. Not just the latest in the current project.

Here's something I generated in my coding AI for Powershell:

`Get-ChildItem -Recurse | Select-String -Pattern '_0x112fa8' | ForEach-Object { $_.Line.Substring(0, [Math]::Min(80, $_.Line.Length)) }`

Breakdown of the Command:

- Get-ChildItem -Recurse: This command retrieves all files in the current directory and its subdirectories.

- Select-String -Pattern '_0x112fa8': This searches for the specified pattern in the files.

- ForEach-Object { ... }: This processes each match found.

- Substring(0, [Math]::Min(80, $_.Line.Length)): This limits the output to a maximum of 80 characters per line.

---

Hopefully this should work for Windows devs out there. If not, reply and I'll try to modify it.

If it produces no output, does that mean that there's no code that could act in the future? I first acted out of nerves and deleted the whole node-modules and package.lock in a couple of freshly opened Astro projects, curious if I should considered my web surfing to still be potentially malicious

convenience script that checks through package.json dependency tree + a couple malicious binary patterns:

https://gist.github.com/edgarpavlovsky/695b896445c19b6f66f14...

As a C developer, having being told for a decade that minimising dependencies and vendoring stuff straight from release is obsolete and regressive, and now seeing people have the novel realisation that it's not, is so so surreal.

Although I'll still be told that using single-header libraries and avoiding the C standard library are regressive and obsolete, so gotta wait 10 more years I guess.

npm's recent provenance feature fixes this, and it's pretty easy to setup. It will seriously help prevent things like this from ever happening again, and I'm really glad that big packages are starting to use it.

You can do some weird verify thing on your GitHub builds now when they publish to npm, but I've noticed you can still publish from elsewhere even with it pegged to a build?

But maybe I'm misunderstanding the feature

Do you do this in your CI as well? E.g. if you have a server somewhere that most would run `npm install` on builds, you just `git clone` into your node_modules or what?

> The alternative is to import packages directly from the (git) repository.

That sounds great in theory. In practice, NPM is very, very buggy, and some of those bugs impact pulling deps from git repos. See my issue here: https://github.com/npm/cli/issues/8440

Here's the history behind that:

Projects with build steps were silently broken as late as 2020: https://github.com/npm/cli/issues/1865

Somehow no one thought to test this until 2020, and the entire NPM user base either didn't use the feature, or couldn't be arsed to raise the issue until 2020.

The problem gets kinda sorta fixed in late 2020: https://github.com/npm/pacote/issues/53

I say kinda sorta fixed, because somehow they only fixed (part of) the problem when installing package from git non-globally -- `npm install -g whatever` is still completely broken. Again, somehow no one thought to test this, I guess. The issue I opened, which I mentioned at the very beginning of this comment, addresses this bug.

Now, I say "part of of the problem" was fixed because the npm docs blatantly lie to you about how prepack scripts work, which requires a workaround (which, again, only helps when not installing globally -- that's still completely broken); from https://docs.npmjs.com/cli/v8/using-npm/scripts:

    prepack
    
        - Runs BEFORE a tarball is packed (on "npm pack", "npm publish", and when installing a git dependencies).

Speaking of TypeScript, the TypeScript compiler developers ran into this very problem, and have adopted this workaround, which is to invoke a script from the npm prepare script, which in turn does some janky checks to guess if the execution is occuring from a source tree fetched from git, and if so, then it explicitly invokes the prepack script, which then kicks off compiler and such. This is the workaround they use today:

https://github.com/cspotcode/workaround-broken-npm-prepack-b...

... and while I'm mentioning bugs, even that has a nasty bug: https://github.com/cspotcode/workaround-broken-npm-prepack-b...

Yes, if the workaround calls `npm run prepack` and the prepack script fails for some reason (e.g. a compiler error), the exit code is not propagated, so `npm install` will silently install the respective git dependency in a broken state.

How no one looks at this and comes to the conclusion that NPM is in need of better stewardship, or ought to be entirely supplanted by a competing package manager, I dunno.

This is true, but I've also run into legitimate password fields on different domains. Multiple times. The absolute worst offender is mobile app vs browser.

Why does the mobile app use a completely different domain? Who designed this thing?

Yeah, a password manager/autofill would have set off some alarms and likely prevented this, because the browser autofill would have detected a mismatch for the domain npmjs.help.

And I guess you can just withdraw your funding from him any time.

Have you used a Microsoft product lately? So many bigco's publishing their org chart as login domains.

I get the sentiment behind 'just use a password manager', but I don’t think victim-blaming should be the first reflex. Anyone can be targeted, and anyone can fail, even people who do 'everything right'.

Password managers themselves have had vulnerabilities, browser autofill can fail, and phishing can bypass even well-trained users if the attack is convincing enough.

Good hygiene (password managers, MFA, domain awareness) certainly reduces risk, but it doesn’t eliminate it. Framing security only as a matter of 'individual responsibility' ignores that attackers adapt, and that humans are not perfect computers. A healthier approach would be: encourage best practices, but also design systems that are resilient when users inevitably make mistakes.

How does someone intelligent with 2FA get pwned? Serious question.

Real registries do[1], npm is just amateur-hour which is why its usage is typically forbidden in enterprise contexts.

[1] https://www.debian.org/doc/manuals/securing-debian-manual/de...

Mmm. But how does the package registry know which signing keys to trust from you? You can't just log in and upload a signing key because that means that anyone who stole your 2FA will log in and upload their own signing key, and then sign their payload with that.

I guess having some cool down period after some strange profile activity (e.g. you've suddenly logged from China instead of Germany) before you're allowed to add another signing key would help, but other than that?

< developers downloading CI artifacts and manually signing and uploading them

Hell no. CI needs to be a clean environment, without any human hands in the loop.

Publishing to public registries should require a chain of signatures. CI should refuse to build artifacts from unsigned commits, and CI should attach an additional signature attesting that it built the final artifact based on the original signed commit. Public registries should confirm both the signature on the commit and the signature on the artifact before publishing. Developers without mature CI can optionally use the same signature for both the source commit and the artifact (i.e. to attest to artifacts they built on their laptop). Changes to signatures should require at least 24 hours to apply and longer (72 hours) for highly popular foundation packages.

I'm a fan of post-facto confirmation. Allow CI/CD to do the upload automatically, and then have a web flow that confirms the release. Release doesn't go out unless the button is pressed.

It removes _most_ of the release friction while still adding the "human has acknowledged the release" bit.

https://docs.npmjs.com/generating-provenance-statements

I like this idea and could see it being visually represented as a faint red/green bar behind the URL text in the address bar, with a greater amount of the bar being red when the domain is less trusted.

As for developers trusting a plugin that reaches out to an external location to determine the reputation of every website they visit seems like a harder sell though.

that's a good one not perfect for sure, hackers would just start buying domains earlier but still...

There are curated lists over newly registered domain names that some security software uses so it should be easy to add without any privacy issues.

I wonder why they didn't add something more nefarious that can run on developers machines while they were at it, would it have been too easy to see? It was caught very quickly anyway.

Etherscan has tagged these addresses already. As of this check, none of the other block explorers have. Etherscan - yes - https://etherscan.io/address/0x4Cb4c0E7057829c378Eb7A9b174B0...

Mempool.space - no Blockchair - no Tronscan - no Blockcypher.com - no Blockread.io - no

that will still affect users of your website that uses these packages, tho.

Did you receive the email in a similar time window? I'm trying to think of ways to scan other repositories for signs of compromise.

Yeah, I get that learning the codes is a little annoying, but not actually harder than finding, incorporating, and learning one of the APIs here. Also one is standard while the other is not. Seems a bit nuts to use a package for this.

The advisories on GitHub were/are weird for several reasons:

1. The version matching was wrong (now fixed).

2. The warning message is (still) exaggerated, imo, though I understand why they’d pass the liability downstream by doing so.

I mean the statement is pretty clear

>Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

It sounds like the package then somehow executes and invites other software onto the machine. If something else has executed then anything the executing user has access to is now compromised.

I agree, and this is arguably the best reason to use a password manager (with the next being lack of reuse which automatically occurs if you use generated passwords, and then the next being strength if you use generated passwords).

I generally recommend Google's to any Android users, since it suggests your saved password not only based on domain in Chrome browser, but also based on registered appID for native apps, to extend your point. I'm not sure if third party password managers do this, although perhaps it's possible for anti-monopoly reasons?

using NPM at all must be treated as a liability at this point. it's not the first and definitely not the last time NPM got pwned this hard.

It isn't uncommon in crypto ecosystems for the core foundation to shovel slop libraries on application developers.

> Don't update dependencies unless necessary

And get yourself drowning in insurmountable technical debt in about two months.

JS ecosystems moves at an extremely fast pace and if you don't upgrade packages (semi) daily you might inflict a lot of pain on you once a certain count of packages start to contain incompatible version dependencies. It sucks a lot, I know.

Can you expand on "use Deno" for installing dependencies? I assume you don't mean to use Deno as the runtime, just for dependency management.

Passkeys already solve for this, we just have to get past the FUD.

I also received the same phishing email and I only have packages with a few thousand downloads per week.

And the author's prompt response.

> Size: 3124 kB

Hey, that's a pretty good reproduction of npmjs

I also see:

- https://github.com/advisories/GHSA-hfm8-9jrf-7g9w

- https://github.com/advisories/GHSA-5g7q-qh7p-jjvm

- https://github.com/advisories/GHSA-8mgj-vmr8-frr6

- https://github.com/advisories/GHSA-m99c-cfww-cxqx

I wonder if they're all from the same thing, they all popped up at the same time.

edit: they do appear to all be the same thing, and the advisory version wildcard is wrong: https://github.com/github/advisory-database/issues/6099

No. A now unavailable version, `debug@4.4.2` was unpublished by npm, which is the only vulnerable version in question.

Edit: However, I think the reason the security advisory marks the entire package at the moment, is because there is no mechanism in npm to notify users a version with an exploit is currently installed. `npm audit` looks at the versions configured, not installed.

The security advisory triggering this warning forces everyone to reinstall packages today, in case 4.4.2 was installed.

aren't these already nuked and show up in the "npm audit" command?

how about:

grep -r "_0x112fa8"

Nathan, do you work for Socket? I think you should at least disclose that when sharing posts here.

(This was originally posted to https://news.ycombinator.com/item?id=45168413 but we merged the threads)

Just ran a script to do this – doesn't seem like there's much going in, other than one test transaction.

The discrepancy comes from how npm packages are published. What you see on GitHub is whatever the maintainer pushed to the repo, but what actually gets published to the npm registry doesn’t have to match the GitHub source. A maintainer (or someone with access) can publish a tarball that includes additional or modified files, even if those changes never appear in the GitHub repo. That’s why the obfuscated code shows up when inspecting the package on npmjs.com.

As for the “0 downloads” count: npm’s stats are not real-time. There’s usually a delay before download numbers update, and in some cases the beta UI shows incomplete data. Our pipeline picked up the malicious version because npm install resolved to it based on semver rules, even before the download stats reflected it. Running the build locally reproduced the same issue, which is how we detected it without necessarily incrementing the public counter immediately.

> How is it possible that this code (line 9 of the index.js) isn't present in the source github repo, but can be seen in the beta feature of npmjs.com

You may also be interested in npm package provenance [1] which lets you sign your npm published builds to prove it is built directly from the source being displayed.

This is something ALL projects should strive to setup, especially if they have a lot of dependent projects.

1: https://github.blog/security/supply-chain-security/introduci...

> DO. NOT. USE. THIS. PACKAGE

> Used by 9.9m

https://github.com/qix-/node-simple-swizzle

Dependabot now supports "cooldown" config for this case:

https://github.blog/changelog/2025-07-01-dependabot-supports...

If the update isn't from a security alert, I let most dependabot PRs marinate for about a week precisely for this reason. Not the most scientific approach, but less stressful for sure.

How did they get a valid ssl cert though?

Any write up? I would like to learn more to avoid.

What about SSL?

How did that get past TLS checks? They used Unicode characters that visually looked like amazon.com ?

That's not... how that works, unless you clicked through a very loud, obvious TLS warning.

Meanwhile in Python: 134 million weekly downloads, seemingly slowly trending upward over time, for https://pypistats.org/packages/six which provides third-party compatibility for a version of Python that dropped support over five years ago.

I wrote it 10 years ago, I think before Node was v1, and forgot about it for a long time. This was back before we had spreads, classes, typescript, and had to use DOM arrays and other weird structures, and where `arguments` wasn't an array but an object.

    > (function() { return Array.isArray(arguments); })()
    false

You don’t get it. People don’t add “is-arrayish” directly as a dependency. It goes like this:

1) N tiny dubious modules like that are created by maintainers (like Qix)

2) The maintainer then creates 1 super useful non-tiny module that imports those N dubious modules.

3) Normal devs add that super useful module as a dependency… and ofc, they end up with countless dubious transitive dependencies

Why maintainers do that? I don’t think it’s ignorance or laziness or lack of knowledge about good software engineering. It’s because either ego (“I’m the maintainer of N packages with millions of downloads” sounds better than “I’m the maintainer of 1 package “), or because they get more donations or because they are actually planning to drop malware some time soon.

And at the other extreme, it takes TC39 seven years to bikeshed half of a decent implementation of Python's context managers: https://github.com/tc39/proposal-explicit-resource-managemen...

On one extreme, we have standards committees that move glacially, and on the other, we have a chaotic package ecosystem moving faster than is prudent. The two are related.

That domain (npmjs[.]help) has been taken down. Looks like it was purchased and started hosting on September 5th, 2025.

Off the top of my head, you could include your own checksum in the payload. Their code only modifies the address. Nothing would prevent them from reverse engineering checksum, too.

There are ways to detect a replaced/proxied global window function too, and that's another arms race.

> Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight.

Unless this is a situation that could've been easily avoided with a password manager since the link was from a website not in your manager's database, so can't happen to anyone following security basics, and the point of discussing the oversight instead of just giving up is to increase the share of people who follow the basics?

One thing I've been thinking of is to restrict global access to packages. Something like ansi-styles doesn't need access to the crypto global, or to the DOM, or make web requests, etc. So if you can sandbox individual libraries, you can decrease the attack surface a lot.

You could imagine that a compromised pad-left package could read the contents of all password inputs on the page and send it to an attacker server, but if you don't let that package access the document, or send web requests, you can avoid this compromise.

> How do the end user protect themselves at this point? Especially the average user?

Don't use unregulated financial products. The likelihood of a bank being hit by this isn't zero - but in most parts of the world they would be liable and the end user would be refunded.

> How do you prevent supply chain compromises like this?

Strictly audit your code.

There's no magic answer here. Oh, I'm sure you can throw an LLM at the problem and hope that the number of false positives and false negatives don't drown you. But it comes down to having an engineering culture which moves slowly and doesn't break things.

> How do you prevent supply chain compromises like this? Take a look at https://github.com/AikidoSec/safe-chain and https://intel.aikido.dev/?tab=malware! Disclaimer: I work at Aikido Security :)

Packj [1] detects malicious PyPI/NPM/Ruby/PHP/etc. dependencies using behavioral analysis. It uses static+dynamic code analysis to scan for indicators of compromise (e.g., spawning of shell, use of SSH keys, network communication, use of decode+eval, etc). It also checks for several metadata attributes to detect bad actors (e.g., typo squatting).

1. https://github.com/ossillate-inc/packj

> - How do the end user protect themselves at this point? Especially the average user?

- Install as little software as possible, use websites if possible.

- Keep important stuff (especially cryptocurrency) on a separate device.

- If you are working on a project that pulls 100s of dependencies from a package registry, put that project on a VM or container.

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

I can provide you with some missing background as I was a prior full time JavaScript/TypeScript developer for 15 years.

Most people writing JavaScript code for employment cannot really program. It is not a result of intellectual impairment, but appears to be more a training and cultural deficit in the work force. The result is extreme anxiety at the mere idea of writing original code, even when trivial in size and scope. The responses vary but often take the form of reused cliches of which some don't even directly apply.

What's weird about this is that it is mostly limited to the employed workforce. Developers who are self-taught or spend as much time writing personal code on side projects don't have this anxiety. This is weird because the resulting hobby projects tend to be substantially more durable than products funded by employment that are otherwise better tested by paid QA staff.

As a proof ask any JavaScript team at your employment to build their next project without a large framework and just observe how they respond both verbally and non-verbally.

Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one trivial-thing function, other unrelated trivial things can still be used, because they are not bundled in the same package.

A comprehensive library might offer a more neat DX, but you'd have to ship library code you don't use. (Yes, tree-shaking exists, but still is tricky and not widespread.)

This conversation been a thing since at least the leftpad event. It's just how the js ecosystem works it seems. The default library is too small perhaps?

It's easier to find something frustrating in large code changes than in single line imports, even if the effective code being run is the same -- the PR review looks cleaner and safer to just import something that seems "trusted".

I'm not saying it is safer, just to the tired grug brain it can feel safer.

Same reason they do in rust.

The rust docs, a static site generator, pull in over 700 packages.

Because it’s trivial and easy

"JS people" don't, but certain key dependencies do, and there are social / OSS-political reasons why.

Why do "Java people" depend on lowrie's itext? Remember the leftpad-esque incident he initiated in 2015?

You typically don't. But a lot of packages that you do install depend on smaller stuff like this under the hood (not necessarily good and obviously better handled with bespoke code in the package, but is is what it is).

This is spreading everywhere, Rust, Python, ...

Which of these would you prefer to reimplement?

Debug, chalk, ansi-styles?

---

You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years.

Extreme aversion to NIH syndrome, perhaps? I agree that it's weird. Sure, don't try to roll your own crypto library but the amount of `require('left-pad')` in the wild is egregious.

It's a tricky thing because what if the update fixes a critical vulnerability? Then you'd be stuck on the exploitable version for X months longer

Run anything in some sort of container or sandbox

Noticed that after ten mins, contacted author immediatly and he seems to be working on it / restoring his account / removing malware on published packages.

Kinda "proud" on it haha :D

While true, this is also an eye opening event of how much worse it could be if it was more generic and not limited to crypto wallet addresses.

If an exchange got compromised there's no way you would know you're sending to the attackers address

How is it terrifying? They clicked through a 2FA reset email, a process that I have never, and will never need to go through, and seemingly one that they didn't even initiate.

I dislike web3 and the overuse of crypto as much as you do. But look at the nature of the exploit. It isn't limited to crypto or web3. There are other secrets and sensitive information that browsers regularly hold in their memory. What about them?

I must admit I was wary of them at first but now I use them on everything I can and it's more convenient.

What if the latest patch is (claiming to be) a security fix? Then that's 3 days of more insecurity.

Would it be spotted quickly if nobody got the update though? It'd probably just go undetected for 3 days instead. In this case one team spotted it because their CI picked up the new version (https://jdstaerk.substack.com/p/we-just-found-malicious-code...).