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

Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

socket.dev

Post reply on HN
Print view View original

261–270 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#261

Post by bananadonkey »

fauigerzigerk wrote: post #181
eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

I use a separate dev user account (on macOS) for package installations, VSCode extensions, coding agents and various other developer activities. I know it's far from watertight (and it's useless if you're working with bitwarden itself), but I hope it blocks the low hanging fruit sort of attacks.

Check your home folder permissions on macos, last time I checked mine were world readable (until I changed them). I was very surprised by it, and only noticed when adding an new user account for my wife.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#262

Post by erans »

The part that seems most important here is that npm install was enough.

Once the compromise point is preinstall, the usual "inspect after install" mindset breaks down. By then the payload has already had a chance to run.

That gets more interesting with agents / CI / ephemeral sandboxes, because short exposure windows are still enough when installs happen automatically and repeatedly.

Another thing I think is worth paying attention to: this payload did not just target secrets, it also targeted AI tooling config, and there is a real possibility that shell-profile tampering becomes a way to poison what the next coding assistant reads into context.

I work on AgentSH (https://www.agentsh.org), and we wrote up a longer take on that angle here:

https://www.canyonroad.ai/blog/the-install-was-the-attack/

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#263

Post by fragmede »

Sohcahtoa82 wrote: post #138
reactordev wrote: post #113

Earlier quoted context omitted.

that's our future... with AI. Engineers that don't know the difference between client-side convenience and server-side injection, how to configure `php.ini`, or that no synchronized password manager is safe. While the OAuth scope is `*`, and CORS is what you drink on the weekend.

Can someone explain why people struggle with CORS? The full strength of the SOP applies by default. CORS is an in security feature that relaxes the SOP. Unless you need to relax the SOP, you shouldn't be enabling CORS, meaning you shouldn't be sending an Access-Control-Allow-Origin header at all. If your front-end at www.example.com makes calls to api.example.com, then it's simple enough to just add www.example.com t…

That simple prod example isn't where people struggle with CORS. It's during development and I've got assets on Cloudflare and AWS and GCP and localhost:3000 and localhost:8000, and localhost:3001 and then a VM in Hetner at API.example.com because why not, that shit gets complicated and people get confused and lost. I mean, yeah, don't do that, but CORS gets complicated once the project gets enough teams involved.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#264

Post by slekker »

abustamam wrote: post #255
eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

I like the idea of a cool down. But my next question is would this have been caught if no one updated? I know in practice not everyone would be on a cool down. But presumably this comprise was only found out because a lot of people did update.

It's a trade off for sure, maybe if companies could have "honeypot" environments where they update everything and deploy their code, and try to monitor for sneaky things.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#266

Post by yangikan »

ruuda wrote: post #51

https://github.com/doy/rbw is a Rust alternative to the Bitwarden CLI. Although the Rust ecosystem is moving in NPM's direction (very large and very deep dependency trees), you still need to trust far fewer authors in your dependency tree than what is common for Javascript.

Is there any downside to using the firefox builtin password manager?

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#267

Post by seanw444 »

embedding-shape wrote: post #257
seanw444 wrote: post #231

Earlier quoted context omitted.

It is baffling to me that a language that is as focused on safety/security as Rust decided to take the JavaScript approach to their ecosystem. I find it rather contradictory.

That's because you're mixing things. "Rust the language" isn't the one starting new projects and add new dependencies that have hundreds of dependencies of their own, this is the doing of developers. The developers who built Rust with a focus on safety and security is not the same developers mentioned before.

That's true. But it does seem like a logic result of having no real standard library. That lone fact has kept me away from Rust for real projects, because I don't want to pull in a bunch of defacto-standard-but-not-officially dependencies for simple tasks. That's probably a large contributor to the current state of dependency bloat.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#268

Post by pmichaud »

abustamam wrote: post #255
eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

I like the idea of a cool down. But my next question is would this have been caught if no one updated? I know in practice not everyone would be on a cool down. But presumably this comprise was only found out because a lot of people did update.

If I were in charge of a package manager I would be seriously looking into automated and semi automated exploit detection so that people didn't have to yolo new packages to find out if they are bad. The checking would itself become an attack vector, but you could mitigate that too. I'm just saying _something_ is possible.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#269

Post by teiferer »

slekker wrote: post #264
abustamam wrote: post #255

Earlier quoted context omitted.

I like the idea of a cool down. But my next question is would this have been caught if no one updated? I know in practice not everyone would be on a cool down. But presumably this comprise was only found out because a lot of people did update.

It's a trade off for sure, maybe if companies could have "honeypot" environments where they update everything and deploy their code, and try to monitor for sneaky things.

It's easy for malicious code to detect sandboxing.

Also, check out the VW Diesel scandal.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#270

Post by dwattttt »

fragmede wrote: post #252
eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

But how do you know which one is good? If foo package sends out an announcement that v1.4.3 was hacked, upgrade now to v1.4.4 and you're on v1.4.3, waiting a week seems like a bad idea. But if the hackers are the one sending the announcement, then you'd really want to wait the week!

An announcement isn't a quiet action. One would hope that the real maintainers would notice & take action.
Post reply on HN