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 er een bekende groepering achter de cyberaanval zit, die 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 (43)

[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...

[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).

[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

[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.

[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.

[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.

[necessaryevil]

Ik denk dat ik het verhaal niet goed begrijp. Zoals ik het lees, is de onderliggende kwetsbaarheid in Github, de inloggegevens zijn gestolen met een GitHub-Checkmarx-aanval waardoor er een geïnfecteerde package geinstalleerd kaon worden. Maar welke kwetsbaarheid heeft Bitwarden dan opgelost? Het verwijderen van de gëinfecteerde versie?
En wat is dan de relatie met de npm-chain supply chain attack?

[thomasv]

https://www.itnews.com.au...tm_campaign=editors_picks

Zie voor overige supply chain attacks Npm Shai Hulud, dan zie je meer gerelateerd nieuws en waar mijn punt vandaan komt.

[Reactie gewijzigd door thomasv op 24 april 2026 07:46]

[necessaryevil]

Oke, maar dan snap ik de verbanden in het artikel nog niet.

//edit
Ah, NPM en de Github Checkmarx zijn gekoppeld.... toch?

[Reactie gewijzigd door necessaryevil op 24 april 2026 23:02]

[thomasv]

Oke.

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

[Gamebuster]

Install scripts maakt weinig uit als je gewoon commands kan uitvoeren vanuit code toch? Zodra je geinfecteerde script door Node gehaald wordt, is het gewoon game-over.

Beter draai je je meuk in een sandbox (met AI toch al heel handig) of gebruik je gewoon minder dependencies. Bovendien, het is makkelijk om op NPM te haten maar er was er pas nog 1tje in Python/PIP geloof ik die heel breed impact had.

Supply chain attacks worden gewoon super populair, zeker nu AI met gemak allemaal dependencies naar binnen kan harken en niemand leest of kijkt wat er uitgevoerd wordt.

[Reactie gewijzigd door Gamebuster op 24 april 2026 08:29]

[Nark0tiX]

Gewoon geen javascript meer gebruiken... Zelf gebruik ik vooral nog rust, veiliger en groener.

[Snippo]

Wat gebruik je voor frontend? Ik heb even geïnventariseerd, maar bijv. een volledige Progressive Web Application (PWA) maken met Rust lijkt (nog) niet mogelijk. Zelf loop ik er vaak tegenaan dat de eerste 90% vaak probleemloos gaat, maar die laatste 10% blijkt dan überhaupt niet ondersteund. Het TS/JS ecosysteem is dan weer zo groot dat er uiteindelijk dan wel ergens een oplossing te vinden is in een npm package.

[Aduen]

amen

[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.

[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.

[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]

[Cartman!]

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

[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]

[The Third Man]

De verwachting is waar het mis gaat omdat zowat iedereen in elke laag dat pleegt te doen en zelf er geen zorg voor draagt. Die verwacht het weer van diens volgende schakel en zo gaat het verder. Uiteindelijk is het een developer ergens drie hoog achter die ooit de maintainer was, er niks meer mee doet, mails niet leest enzvoort die gehacked wordt en de hele keten neemt de hack over.

Ja het is prutswerk maar er moet ook een prutsverwachting afgeleerd worden om het van andermans degelijk werk af te laten hangen en zelf alleen te hopen dat het goed is.

[Reactie gewijzigd door The Third Man op 24 april 2026 08:15]

[junkchaser]

Het is misschien niet leuk dat hackers met al dat AI-geweld aan de slag kunnen, maar laten we ook de positieve kant belichten: software zal in recordtempo vele malen beter worden, simpelweg omdat het moet. Bedrijven zullen daardoor vanzelf gedwongen worden om hier volop op in te zetten.

[servies]

Droom lekker door zou ik zeggen. Zolang ze niet het slachtoffer zijn zullen veel bedrijven zich niet gedwongen voelen om extra aandacht aan veiligheid te geven.

[exyll]

Wanneer worden package niet gewoon standaard gesigned? Ik weet niet precies hoe NPM architectuur in elkaar steekt maar neem NuGet. Dat ondersteund signing maar verplicht het niet. Als de login van gecompromiteerd is is signing de 2e laag.

Waarom dit niet standaard is bij alle package en packages repositories is mij een raadsel. Je zou denken dat BLOB stores (want dat zijn packages) dit wel zo'n beetje gestandaardiseerd zou hebben na decennia maar helaas