Bitwarden lost kwetsbaarheid in CLI-tool op na geïnfecteerd npm-package

De Bitwarden-tool Command-line Interface (CLI) was vandaag voor een korte tijd onveilig vanwege geïnfecteerde npm-packages. De makers van de wachtwoordmanager hebben het probleem opgelost. Cybercriminelen maakten voor de aanval gebruik van een supplychainaanval.

De gecompromitteerde versie is @bitwarden/cli@2026.4.0. Op de downloadpagina van deze versie staat nadrukkelijk dat het om een onveilige versie gaat. Volgens Bitwarden was de geïnfecteerde versie ongeveer anderhalf uur online. Voor zover bekend is er geen toegang tot de wachtwoordkluis van het reguliere Bitwarden-programma verkregen.

Bitwarden CLI is een tool waarmee gebruikers via een commandline-interface toegang kunnen krijgen tot hun wachtwoordkluis van Bitwarden. Het gaat om een speciale tool die de meeste Bitwarden-gebruikers niet zullen gebruiken.

Er zijn aanwijzingen dat een bekende groepering achter de cyberaanval zit en eerder verantwoordelijk was voor de onderliggende GitHub-Checkmarx-aanval. Daarbij lijkt het erop dat de aanval via een bekende aanvalstechniek gaat waarbij criminelen inloggegevens stelen en zo geïnfecteerde versies van de beoogde software kunnen verspreiden. In dit geval werd er een GitHub Action-kwetsbaarheid misbruikt.

De verspreiding van de malafide software gebeurt via npm-packages, bestanden met JavaScript-code die soms automatisch via de npm-packagemanager verspreid worden. Tweakers schreef een achtergrondverhaal over deze supplychainaanval.

Reacties (31)

[thomasv]

En weer een npm supply chain attack. Stap over op pnpm voor je builds zodat post install scripts niet meer standaard uitgevoerd worden, en faseer node/npm op termijn gewoon uit als je kan. Het blijft dweilen met de kraan open door de nested dependency hell van node applicaties...

[GertMenkel]

De preinstall los je daarmee op, maar volgens https://research.jfrog.com/post/bitwarden-cli-hijack/ is de executable die gegenereerd wordt ook geïnfecteerd. Daar doe je niks tegen.

Mocht je om wat voor reden dan ook nog op NPM moeten blijven zitten, is "npm config set ignore-scripts true" het testen waard.

[R4gnax]

"npm config set ignore-scripts true"

Terzijde: het is zo vreselijk slecht dat er geen allow-scripts optie is die specifiek enkel packages die met naam en versie op een toegestane lijst staan, wel lifecycle scripts laat draaien.

O.a. als je van het patch-package package gebruik maakt om op git-diff gebaseerde hot-patches op andere packages toe te passen, bijv. hangende een officiële bugfix, dan is de allesomvattende ignore-scripts configuratie-vlag gewoon geen optie.

[Reactie gewijzigd door R4gnax op 23 april 2026 18:59]

[Hvdbnl]

Ja het is jammer dat het niet in NPM zelf zit, je kan het wel voor elkaar krijgen met een dependency: https://www.npmjs.com/package/@lavamoat/allow-scripts

Daarnaast zijn er nog een paar die je kan gebruiken om nog meer te blokkeren en wat 'veiliger' te zijn:

npm config set allow-git none

Daarmee voorkom je dat je dat je git repositories download die een .npmrc kan hebben die executables kan overriden (en daarmee je ignore-scripts kan passeren)

En je kan een default cooldown periode instellen:

npm config set min-release-age 3

De release moet dan 3 dagen oud zijn, kans dat de vulnerability dan nog niet gevonden is is vrij klein.

En dan natuurlijk altijd npm audit en signatures checken

npm audit
npm audit signatures --json --include-attestations

[R4gnax]

npm config set min-release-age 3

Dat is denk ik de belangrijkste van het setje.

Daarmee voorkom je dat je dat je git repositories download die een .npmrc kan hebben die executables kan overriden (en daarmee je ignore-scripts kan passeren)

Daarmee ben je er echter nog niet omdat packages ook bin commando's kunnen optuigen. Kwaadwillenden kunnen bekende commando's zoals git of npm aliasen waardoor hun malware er achteraan gechaind wordt.

(Dat is niet specifiek hoe ze hier bij Bitwarden binnenkwamen, vziw. maar wel kort in het verleden al eens gebeurd in andere gevallen.)

[Reactie gewijzigd door R4gnax op 23 april 2026 19:33]

[Hvdbnl]

Hum ja dat bedoelde ik te zeggen ermee eigenlijk
Als je git repo's toestaat als source, dan ben kan je de sjaak zijn omdat ze van alles kunnen alliassen.

[thomasv]

Zie pnpm, die heeft dit dus wel.

[himlims_]

Hoe komt het dat bij npm sneller/vaker lijkt te gebeuren dan andere package-tools?

Zit er fundamenteel iets verkeerd?
Is de dienst populair(der)? Wat het voor een hacker/scripter interessant maakt omdat breed toegepast wordt?
Of is het slordigheid? Als in men zoek package “hippe-functie-ontwikkelaarsbuild-2.4” en iemand biedt een aangepaste variant aan met de naam “hippe-functie-ontwikkelaarbuild-2.4” (zonder s).

[Martinspire]

Populairder en nog niet alle packages hebben de laatste implementatie van de beveiliging. Er zijn namelijk wel maatregelen genomen om het minder makkelijk te maken packages te uploaden door tokens te kapen, maar dan moet je die wel gebruiken. Verder had Bitwarden dit ook zeker kunnen voorkomen. Niet alleen met PNPM, maar ook door package versies vast te zetten en niet toe te staan dat je packages van nieuwer dan x-tijd te laten gebruiken, ongeacht of er een post-install bij zit.

[Oon]

Ik denk gewoon massa; npm is de meestgebruikte package manager voor het JS ecosysteem. Daarnaast heb je als je het vergelijkt met bijv. Composer weer een heel andere attack surface, want daar draaiten pakketjes vaak niet lokaal voor development & builds maar op een dichtgetimmerde webserver, terwijl NodeJS hele 'leuke' CLI tools heeft (zoals bitwarden-cli) waar je heel veel mee kunt winnen als hacker

[thomasv]

In een notendop waar ik denk dat de zwakste schakel zit naast library maintainers die in phishing trappen op een niveau zo ernstig dat ze hun 2FA security uit hebben laten schakelen door de bewoording en werkwijze van de aanvallers ten tijde van de Shai Hulud supply chain attacks is dat je een enorme library dependency tree kan hebben. Elke library heeft soms zn eigen dependencies weer die ook gedownload worden. Stel je een diepgaande keten voor waar dan een of meerdere van die libraries in een recente versie malware/Trojan/crypto stealers aan toe voegt en dan ga je nat: https://lexi-lambda.github.io/blog/2016/08/24/understanding-the-npm-dependency-model/

CI/CD maakt dit exponentieel erger in een standaard npm configuratie en wanneer een developer applicaties in een node applicatie niet op versie vastgepind heeft, en recente attacks laten zien dat veel developers daar tot dusver niet de noodzaak van inzien omdat ze recente versies van dependencies willen gebruiken juist om CVEs te voorkomen. Een unit of integratie test faalt niet omdat er een crypto stealer meegekomen is dus je geïnfecteerde applicatie krijgt groen licht en wordt gedeployed.

[Reactie gewijzigd door thomasv op 23 april 2026 19:32]

[R4gnax]

Hoe komt het dat bij npm sneller/vaker lijkt te gebeuren dan andere package-tools?

Populariteit. NPM heeft een hele grote schietschijf op de rug.
De default configuratie van NPM is ook zeer permissive en niet dichtgetimmerd; en het is een ecosysteem waar heel veel zaterdagochtend-niveau beginnelingen in rond dobberen.

[eindhofer]

isn't it best to set the config to only allow package versions that are at least 7 days old or something?
I'm doing this always in my bunfig for bun.

[thomasv]

Yes

[densoN]

Zijn er ook good/best practices van NCSC of gelijkwaardige instanties die organisaties kunnen meenemen in security requirements bij het selecteren van software vendors?

Mogelijk iets wat te combineren valt met de SBOM-verplichting die de CRA oplegt?

[Martinspire]

Heel slordig dit. Ben blij dat ik alweer een tijdje over ben naar Proton. Net wat fijnere UX en zo te zien ook betere beveiliging...

[Bedge85]

Tenzij jij iets weet over de wijze waarop Proton software ontwikkeld dat ik niet weet is Proton net zo kwetsbaar als Bitwarden voor een suply chain attack als deze.

[Reactie gewijzigd door Bedge85 op 23 april 2026 19:20]

[Klauwhamer]

Exact. Supply chain attacks zijn extreem lastig om te ondervangen wanneer ze zorgvuldig en met voldoende tijd en toewijding worden uitgevoerd (XZ Utils bijvoorbeeld). Het is ook niet voor niets dat deze met stip op nummer drie wordt getoond op de OWASP-10 vandaag de dag.

[Martinspire]

Ik zou verwachten dat elk weldenkende developer die werkt aan dit soort systemen de beste maatregelen neemt om de repository te beveiligen en externe dependencies vast te zetten. Dat dit mogelijk was op deze manier is gewoonweg prutswerk.

[Cartman!]

Je verwacht maar weet het niet dus kan Proton net zo goed in dezelfde val trappen.

[Webgnome]

En dan nog, dependencies vast zetten. Wanneer doe je dan een upgrade? Controleer je vervolgns de code van ELKE module en hun submodules tot in den treure? Of doe je dat geautomatiseerd ( hoe ? ). Dit soort dingen kunnen helaas gebeuren en zullen met de huidige aanvallen op repo's steeds vaker gaan voor komen ben ik bang.

[Powerblast]

Ik weet niet of er iets bij NPM en Javascript eco system bestaat maar bijvoorbeeld Rust heeft iets in de trend van cargo-vet. Dit is een soort van community based review systeem dat je vervolgens kan laten nagaan of er al iemand een bepaalde versie van een library gereviewed heeft.

Dit betekent wel nog altijd dat je een bepaalde base versie moet vertrouwen ookal heb je die zelf niet gereviewed en misschien anderen ook nog niet. Vanaf dan is het principe enkel de changes die gebeuren reviewen vooraleer je iets binnen haalt.

[WK100]

Kleine packages faseer ik uit door lokale code. Niet-uitgefaseerde (transitive) deps bij updates onder het vergrootglas. Grote deps van betrouwbare partijen. Scanning-proxy met pin op het pad tussen registry en mijn machines. Vertraging van 3d tussen release en implementatie.

Ijverig m.b.t. reproducible builds en dichttimmeren package managers.

Niet perfect maar tot nog toe (10Y) ben ik hierdoor niet geraakt.

[Reactie gewijzigd door WK100 op 23 april 2026 21:11]

[Martinspire]

Dependabot e.d. kunnen gewoon zoeken naar updates en deze toepassen als alle tests slagen, maar daar kun je met PNPM dus een delay op zetten zodat ie niet te nieuwe packages download (tenzij je er een uitzondering voor maakt). En omdat je versienummers vast zet, gaat er niet zomaar iets gedownload worden wat je nog niet getest hebt. Om nog niet te spreken over simpelweg scannen van je codebase inclusief dependencies om te zorgen dat het ook nooit op de main branch komt te zitten. Ook zijn er betaalde diensten om dit te beveiligen en ik mag van een password manager verwachten dat ze toch wel het absolute minimum doen wat beveiliging van de codebase betreft...

[Reactie gewijzigd door Martinspire op 24 april 2026 01:13]

[Powerblast]

Vastzetten doen ze waarschijnlijk wel, tot ze gaan upgraden. En dan haal je op dat moment nog altijd een versie binnen die mogelijk geïnfecteerd is. Enige wat daar tegen helpt is elke commit van elke dependency manueel gaan reviewen voor je wat upgrade. Het moet je dan alsnog opvallen dat er wat vreemds gewijzigd is, of de code wordt obfuscated (dat is ook een bekende bij dergelijke attacks). Anders glipt het er alsnog gewoon door.

Ik wil dus maar zeggen, ik kan uit de beschrijving niet afleiden dat het prutswerk is. Dit kan mijn inziens elke developer overkomen. Dat is het vervelende aan supply chain attacks.

[Reactie gewijzigd door Powerblast op 23 april 2026 20:43]

[Mijzelf]

Hoe kan een commandline tool last hebben van npm problemen? Npm gaat toch alleen over javascript? Of is die commanline tool ook in javascript geschreven?

[Creesch]

Typescript, wat een superset is van javascript. Aangezien Node.js javascript beschikbaar maakt als backend scripting taal is het prima mogelijk om CLI tooling er mee te schrijven. Of het een goed idee is daar zijn de meningen nogal over verdeeld.

[Cartman!]

Ik kan aanraden om gebruik te maken van iets als https://github.com/AikidoSec/safe-chain die commandos wrapped van oa npm en zo tegen een lijst van malafide packages checkt. Ook is default ingesteld dat n package pas na een dag te downloaden is.

[Byte]

Ik maak gebruik van een Spotlight applicatie welke de mogelijkheid heeft om direct mijn Bitwarden wachtwoordmanager aan te spreken. Zover ik weet heb ik niets geüpdatet (doe ik normaalgesproken via Homebrew). Is er een manier om te controleren of je kwetsbaar bent of bent geweest? Wellicht dat auto update iets op de achtergrond heeft gedaan wat ik niet in de gaten heb gehad. Zij geven aan dat er geen sporen zijn dat er iemand compromised is, maar hoe kan ik dit zelf controleren/bevestigen? Als iemand toegang heeft tot mijn wachtwoordmanager dan heb ik wel een heel groot probleem..

[Reactie gewijzigd door Byte op 23 april 2026 20:44]

[kdekker]

Het is niet alleen npm. Ook via andere distributieroutes kun je geinfeceerd raken. Als ontwikkelaar is het heel handig (npn, pnpn, nuget, vcpkg), maar ondoenlijk om te controleren voor een eindgebruiker. Ik weet niet of het kan, maar er zijn vele andere routes waarbij 'software' jouw kant op komt. OS updates/packages, software die zichzelf update. Gemak dient de mens, maar controleerbaarheid is - afgezien van je virusscanner - niet te doen voor een eindgebruiker.

Nu (nagenoeg) iedereen breedband internet heeft, zie je ook niet of er een paar MB meer of minder binnengeharkt wordt (ook niet verstuurd). Veel software draait voor installeren van een update elevated. Ok, click, maximale rechten. Hoeveel mensen vragen zich af of het klopt?

Ik weet ook niet of open source producten, met commits van alle kanten, meer vatbaar zijn dan een closed-source fabrikant als Microsoft (ik kan me niet herinneren daar iets gelezen te hebben over distributie van infected spul). Linux met rpm's (of andere packages) zijn ook vrij veilig, maar ook daar zitten vaak professionele maintainers achter. Maar ook bitwarden is met dik 200 medewerkers geen kleintje. Vertrouwen we teveel op een fabrikant? Kan een eindgebruiker veel meer doen? Of is alles inmiddels zo complex, dat dit het 'nieuwe normaal' is?

[Jerie]

Node? Voor een CLI password DB client?

Rust Bitwarden CLI heeft hier geen last van https://github.com/doy/rbw ook stateful, en werkt prima met SSO en VaultWarden. Alleen qua MFA zit je aan TOTP. WebAuthn werkt niet. YubiKey OTP, TOTP, en ssh-agent wel.

Persoonlijk gebruik ik enkel read-only functionaliteit.