Until all packages published since this incident are reviewed thoroughly, you cannot be confident that you aren't affected if you did an npm install today at all. Other npm package authors likely had their credentials stolen, which could mean that their packages had malicious updates too, and so on down the chain. And just because this package "only" exfiltrated npm tokens, that doesn't mean the next infections affecting the packages from the compromised tokens have the same script.

I'm even more cynical than your are here.

I think the likelihood of this being the first time a credential-stuffing attack has worked against an npm account is vanishingly small.

While the timeline given makes the response time sound good - it still took a user notification 90 minutes after the first signs they've found so far of the attack to start kicking in the response.

I wonder how many npm packages are widely used but under _way_ less scrutiny than eslint?

Memories of the leftpad.js debacle make me suspect the attacker was not nearly as evil as possible - if they'd chosen a package that lives way down in the dependancy tree of a bunch of popular stuff, but which itself is unlikely to get much scrutiny, this attack might have slid under the radar for a lot longer. (And I've no confidence that this hasn't already happened, possibly multiple times, and this was just a copycat attacker who got "greedy" and foolishly dropped his attack payload onto a popular and heavily scrutinised package...)

> just a copycat attacker who got "greedy" and foolishly dropped his attack payload onto a popular and heavily scrutinised package

On that note, the main reason it was picked up was a bug in the attack itself. If the creator hadn't put the eval in the .on('data'... section and correctly waited until all data was received it wouldn't have thrown the SyntaxError. It may have flown under the radar for even longer.

It steals npm keys right? Maybe it was done in smaller less scrutinized packages and it finally hit pay dirt with a big package like eslint. They still don't know how it was compromised in the first place

Not having done an npm install today at all is why I'm confident.

EDIT: For those who have done an npm install today, I think those commands are still useful and catch the most probable way one could be affected.

Not having done an npm install today _probably_ is grounds for confidence.

It does though, assume that this discovery is the first time this has ever happened. If _I'd_ been considering doing this attack, I'd almost certainly have trialled it on a less popular and hence less likely to have malicious updates noticed package before hitting something like eslint.

Also, the postmortem leaves out any details of whether or how they've audited the rest of the repo - sure they've cleaned up the two packages they know about and revoked some tokens, but I'm not confident they've done the work required to allow confidence that other packages haven't been targeted in this or previous attacks, meaning they might still be leaking new post-revocation tokens.

More broadly, I think this point touches on the idea that you cannot trust code that you did not write yourself. Ken Thompson's Turing Award speech talks about this (https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...).

Note that `eslint-scope` and `eslint-config-eslint` were both affected[1], so duplicate this search for both modules.

[1] https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...

As an aside, doing

    find -exec [...] +

(note + instead of \;) will exec one grep process for as many arguments as possible, instead of one grep process per file.

Thanks for adding those commands.

    find ~ -path '*/eslint-scope/package.json' -exec jq -r 'input_filename+": "+.version' {} +

or just

    jq -r 'input_filename+": "+.version' ~/**/**/eslint-scope/package.json