Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

311–320 of 796 posts

Re: NPM debug and chalk packages compromised

#311

Post by rootlocus »

junon wrote: post #9

Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…

> 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?

Re: NPM debug and chalk packages compromised

#312

Post by naikrovek »

EasyMark wrote: post #205
cgijoe wrote: post #198

Earlier quoted context omitted.

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

[flagged]

I feel like you were trying to help here, but anyone can do this for themselves. Providing information in this way sort of indicates that you don't believe that the person you're replying to can do it on their own, and for that reason it's considered rude.

Re: NPM debug and chalk packages compromised

#313

Post by a022311 »

parliament32 wrote: post #267
9dev wrote: post #245

Earlier quoted context omitted.

In all fairness—npm belongs to GitHub, which belongs to Microsoft. Amateur-hour is both not a valid excuse anymore, and also a boring explanation. GitHub is going to great lengths to enable SLSA attestations for secure tool chains; there must be systemic issues in the JS ecosystem that make an implementation of proper attestations infeasible right now, everything else wouldn't really make sense. So if we're discussin…

The NPM team has repeatedly commented that it's "too hard", effectively, and would discourage new developers from publishing packages. See: https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://news.ycombinator.com/item?id=38645969 https://github.com/npm/cli/commit/5a3b345d6d5d175ea9ec967364...

I don't think I'd trust a package from a new developer like that, so this helps filter out people that don't know how to properly maintain a package. If they really want to make onboarding easier, saying "after e.g. 1000 monthly downloads, you'll need to sign your artifacts" is also a viable solution in my opinion.

Re: NPM debug and chalk packages compromised

#314

Post by dbdr »

FergusArgyll wrote: post #111
nodesocket wrote: post #79

Earlier quoted context omitted.

Yikes, looks legit. Curious what are the destination addresses? Would like to monitor them to see how much coin they are stealing.

0x66a9893cC07D91D95644AEDD05D03f95e1dBA8Af 0x10ed43c718714eb63d5aa57b78b54704e256024e 0x13f4ea83d0bd40e75c8222255bc855a974568dd4 0x1111111254eeb25477b68fb85ed929f73a960582 0xd9e1ce17f2641f24ae83637ab66a2cca9c378b9f Source: https://github.com/chalk/chalk/issues/656#issuecomment-32670...

Next comment:

> Those are swap contract addresses, not attacker addresses. E.g. 0x66a9893cC07D91D95644AEDD05D03f95e1dBA8Af the Uniswap v4 universal router addr.

> Every indication so far is that the attacker stole $0 from all of this. Which is a best-case outcome.

Re: NPM debug and chalk packages compromised

#315

Post by naikrovek »

notmyjob wrote: post #184
rollcat wrote: post #94

Earlier quoted context omitted.

@everyone in the industry, everywhere: Urgency is poison. Please, please put a foot in the door whenever you see anyone trying to push this kind of sh*t on your users. Make one month's advance notice the golden standard. I see this pattern in scam mail (including physical) all the time: stamp an unreasonably short notice and expect the mark to panic. This scam works - and this is why legit companies that try this "in…

Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.

> The solution is to not use email.

and use what? instant message? few things lack legitimacy more than an instant message asking you to do something.

Links in email are much more of a problem than email itself. So tempting to click. It's right there, you don't have to dig through bookmarks, you don't have to remember anything, just click. A link is seductive.

the actual solution is to avoid dependencies whenever possible, so that you can review them when they change. You depend on them. You ARE reviewing them, right? Fewer things to depend on is better than more, and NPM is very much an ecosystem where one is encouraged to depend on others as much as possible.

Re: NPM debug and chalk packages compromised

#316

Post by molsson »

I maintain a package on npm with >1M weekly downloads. I also got the same phishing e-mail, although I didn't click it.. here are the e-mail headers in the phishing e-mail I got:

Return-Path: X-Original-To: martin@minimum.se Delivered-To: martin@minimum.se Received: from mail-storage-03.fbg1.glesys.net (unknown [10.1.8.3]) by mail-storage-04.fbg1.glesys.net (Postfix) with ESMTPS id 596B855C0082 for ; Mon, 8 Sep 2025 06:47:25 +0200 (CEST) Received: from mail-halon-02.fbg1.glesys.net (37-152-59-100.static.glesys.net [37.152.59.100]) by mail-storage-03.fbg1.glesys.net (Postfix) with ESMTPS id 493F2209A568 for ; Mon, 8 Sep 2025 06:47:25 +0200 (CEST) X-SA-Rules: DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FROM_FMBLA_NEWDOM,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MIME_HTML_ONLY,SPF_HELO_NONE,SPF_PASS X-RPD-Score: 0 X-SA-Score: 1.1 X-Halon-ID: e9093e1f-8c6e-11f0-b535-1932b48ae8a8 Received: from smtp-83-4.mailtrap.live (smtp-83-4.mailtrap.live [45.158.83.4]) by mail-halon-02.fbg1.glesys.net (Halon) with ESMTPS id e9093e1f-8c6e-11f0-b535-1932b48ae8a8; Mon, 08 Sep 2025 06:47:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; x=1757637200; d=smtp.mailtrap.live; s=rwmt1; h=content-transfer-encoding:content-type:from:to:subject:date:mime-version: message-id:feedback-id:cfbl-address:from; bh=46LbKElKI+JjrZc6EccpLxY7G+BazRijag+UbPv0J3Y=; b=Dc1BbAc9maHeyNKed/X7iAPabcuvlgAUP6xm5te6kkvGIJlame8Ti+ErH8yhFuRy/xhvQTSj8ETtV f3AElmzHDWcU3HoD/oiagTH9JbacmElSvwtCylHLriVeYbgwhZVzTm4rY7hw/TVqNE5xIZqWWCMrVG wi+k9uY+FUIQAh7Ta2WiPk/A4TPh04h3PzA50zathvYcIsPC0iSf7BBE+IIjdLXzDzNZwRmjgv2ZHW GAx/FRCPFgg0PbVvhJw98vSHnKmjPO/mmcotKFG+MUWkCtTu28Mm46t7MI7z5PrdCXZDA7L1nVnIwE ffIf0zED32Z6tFSJFNmYgFZlD6g+DnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; x=1757637200; d=npmjs.help; s=rwmt1; h=content-transfer-encoding:content-type:from:to:subject:date:mime-version: message-id:feedback-id:cfbl-address:from; bh=46LbKElKI+JjrZc6EccpLxY7G+BazRijag+UbPv0J3Y=; b=DyWvxSOjMf7WfCVtmch+zw63kZ/OOBjcWnh1kIYs/hozgemb9mBIQCMqAdb4vSZChoW5uReVH5+k5 Jaz7UodbPJksVkYWqJOVg6nyx5EaYMYdgcw1+BCct/Sf2ceFwWurhupa6y3FBTFWBYLhcsAXERlx2l IuxWlpZoMDEBqDxjs8yvx/rkBrcd/2SNTcI+ooKJkrBIGBKuELOd3A5C6jlup6JNA4bE7vzP3FUfKw y0357UMnn45zWHm9HvudO4269FRlNjpiJaW7XF1/ANVrnDlNWfUGNQ5yxLZqmQDTtxFI7HcOrF3bTQ O/nrmVOvN9ywMvk/cJU4qGHqD9lT32A== CFBL-Address: fbl@smtp.mailtrap.live; report=arf X-Report-Abuse-To: abuse@mailtrap.io Received: from npmjs.help by smtp.mailtrap.live with ESMTPSA 6aee9fff-8c4b-11f0-87bb-0e939677d2a1; Mon, Sep 08 2025 00:33:20 GMT Feedback-ID: ss:770486:transactional:mailtrap.io Message-ID: X-Mt-Data: bAX0GlwcNW6Dl_Qnkf3OnU.GLCSjw_4H01v67cuDIh2Jkf52mzsVFT_ZEVEe0W6Lf3qzW2LP_TCy93I46MCsoT0pB9HozQkvCw22ORSCt3JBma1G3v9aDEypT1DLmyqlb6hYLF3H7tJCgcxTU5pbijyNaOFtoUMdiTA6jxaONeZbBj.SKUa5CLT5TMpeNHG6oGIiY_jqlU.nQkxGPY3v9E34.Nz4ga8p9Pd_BplftaE~--2CLrluJMY65S5xFl--IISg0olYJu6DVyVDEcJ.AQ~~ MIME-Version: 1.0 Date: Mon, 08 Sep 2025 00:33:20 +0000 Subject: Two-Factor Authentication Update Required To: "molsson" From: "npm" Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Re: NPM debug and chalk packages compromised

#317

Post by eiiot »

dafelst wrote: post #298

I'm curious if anyone is tracking transactions against the wallet addresses in the malicious code - I assume that is essentially the attackers' return on investment here.

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

Re: NPM debug and chalk packages compromised

#318

Post by [deleted] »

mschuster91 wrote: post #240
goku12 wrote: post #99

Earlier quoted context omitted.

Every day brings me another reason to ask the question: "Why the hell did they throw away the idea of mutual TLS?". They then went onto invent mobile OTP, HOTP, TOTP, FIDO-U2F and finally came a full cycle by reinventing the same concept, but in a more complex incarnation - Passkeys.

the UI for client side certificates was shit for years. no one particularly cared. passkeys however are... pretty reasonable.

[deleted]

Re: NPM debug and chalk packages compromised

#319

Post by 12_throw_away »

semverbad wrote: post #213
edent wrote: post #131

Earlier quoted context omitted.

> 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…

So Node also has semver and also package-lock.json, but these are pretty cumbersome. These are a huge part of this. Why a package with 10+ million weekly downloads can just be "updated" like this is beyond me. Have a waiting period. Make sure you have to be explicit. Use dates. Some of the packages hadn't been updated in 7 years and then we firehosed thousands of CI/CD jobs with them within minutes? npm and most of t…

> Why a package with 10+ million weekly downloads can just be "updated" like this is beyond me. Have a waiting period. Make sure you have to be explicit. Use dates.

Yep. Also interesting how many automated security scanners picked this up right away ... but NPM itself can't be bothered, their attitude is "YOLO we'll publish anything"

Re: NPM debug and chalk packages compromised

#320

Post by a022311 »

Joker_vD wrote: post #221
a022311 wrote: post #169

After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.

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…

I suppose you'd register your keys when signing up and to change them, you'd have some recovery passphrase, kind of like how 2FA recovery codes work. If somebody can phish _that_, congratulations.
Post reply on HN