Bitwarden gehackt — waren Ihre Passwörter in Gefahr?

Was ist bei Bitwarden passiert?

Am 22. April 2026 wurde das npm-Paket @bitwarden/cli in Version 2026.4.0 mit Schadcode ausgeliefert — für rund 90 Minuten, bevor Bitwarden die manipulierte Version zurückzog. In diesem Zeitfenster luden 334 Nutzer das Paket herunter.

Der Angriff war kein direkter Einbruch bei Bitwarden, sondern Teil einer breiteren Checkmarx-Supply-Chain-Attacke: Angreifer hatten eine GitHub Action kompromittiert, die in Bitwardens CI/CD-Pipeline zum Einsatz kam. Über diesen Umweg schleusten sie ihren Code in das offizielle npm-Paket ein — als wäre es ein ganz normales Update.

Die Malware im manipulierten Paket sammelte gezielt Entwickler-Zugangsdaten: SSH-Schlüssel, Cloud-Credentials für AWS, Azure und Google Cloud, npm- und GitHub-Tokens. Die erbeuteten Daten wurden über automatisch erstellte öffentliche GitHub-Repositorys unter dem Account des Opfers nach außen geschleust. Bitwarden reagierte innerhalb von 90 Minuten: kompromittierter Zugang gesperrt, manipulierte Version zurückgezogen, betroffene Nutzer informiert.

Waren gespeicherte Passwörter betroffen?

Nein. Der Angriff betraf ausschließlich das CLI — ein Kommandozeilen-Werkzeug, das überwiegend Entwickler und Administratoren nutzen. Die Bitwarden-App, die Browser-Erweiterung und der Web-Tresor waren zu keinem Zeitpunkt betroffen.

Bitwardens Untersuchung fand keinen Hinweis darauf, dass Vault-Daten eingesehen, abgegriffen oder gefährdet waren. Die Verschlüsselung nach dem Zero-Knowledge-Prinzip hätte das auch bei einem tieferen Einbruch verhindert: Ohne Ihr Master-Passwort sind die Tresordaten wertlos — selbst für den Anbieter selbst.

Die reißerischen Headlines „Bitwarden gehackt“ sind technisch nicht falsch, aber irreführend. Kompromittiert wurde ein Werkzeug in der Lieferkette — nicht der Tresor, in dem Ihre Passwörter liegen. Der Unterschied ist entscheidend, denn er bestimmt, ob Sie handeln müssen: Haben Sie das CLI-Paket in Version 2026.4.0 am 22. April installiert, sollten Sie alle auf dem betroffenen System gespeicherten Zugangsdaten erneuern. Haben Sie nur die App oder das Browser-Plugin genutzt, besteht kein Handlungsbedarf.

Warum trifft ein Lieferketten-Angriff auch seriöse Anbieter?

Bei einem Supply-Chain-Angriff greifen Täter nicht das Unternehmen direkt an, sondern einen vorgelagerten Lieferanten — einen Softwarehersteller, ein Open-Source-Projekt oder einen Build-Dienst. Der Schadcode kommt dann als scheinbar legitimes Update zum Anwender. Das macht diese Angriffe so gefährlich: Sie umgehen das Grundvertrauen, auf dem IT aufbaut.

Im Fall Bitwarden war die Kette: Checkmarx (kompromittiert) → GitHub Action → Bitwarden CI/CD → npm-Paket → Entwickler-Rechner. Bitwarden hat nichts falsch gemacht im klassischen Sinne — der Angriff kam von einem Zulieferer, dem sie vertrauten, weil er bisher vertrauenswürdig war.

Der Vorfall reiht sich in eine wachsende Liste ein: SolarWinds (2020), Kaseya (2021), 3CX (2023), XZ Utils (2024) — und jetzt Bitwarden/Checkmarx. Das Muster ist immer dasselbe: Ein einziger kompromittierter Baustein trifft tausende Abnehmer gleichzeitig. Eine ausführliche Einordnung von Supply-Chain-Angriffen und konkreten Schutzmaßnahmen finden Sie in unserem Artikel Angriff über die Hintertür: Warum die Software-Lieferkette zum Risiko wird.

Was bedeutet das für den Mittelstand?

Mittelständische Unternehmen nutzen dieselben npm-Pakete, GitHub Actions und Cloud-Dienste wie Konzerne — ohne deren Security-Operations-Teams. Wird ein weit verbreiteter Baustein kompromittiert, trifft es alle gleichermaßen. Drei Lehren aus dem Bitwarden-Vorfall:

• Software-Bestand kennen. Welche Tools, Pakete und Dienste laufen bei Ihnen? Ohne ein gepflegtes Inventar können Sie im Ernstfall nicht einmal feststellen, ob Sie betroffen sind. Als Bitwarden die kompromittierte Version meldete, mussten betroffene Unternehmen wissen, ob und wo sie das CLI einsetzen — wer das nicht wusste, tappte im Dunkeln.
• Updates kontrolliert einspielen. Automatische Updates sind bequem, aber im schlimmsten Fall liefern sie den Schadcode frei Haus. Ein kontrolliertes Patch-Management prüft und staffelt Updates, bevor sie produktiv ausgerollt werden — genau der Unterschied, der im Bitwarden-Fall 90 Minuten Zeitfenster entschärft hätte.
• Geringste Rechte durchsetzen. Die Bitwarden-Malware konnte SSH-Schlüssel und Cloud-Credentials stehlen, weil diese auf dem betroffenen Rechner lagen. Je weniger Rechte ein System hat, desto kleiner der Schaden. Das Prinzip der geringsten Rechte ist einfach zu formulieren, aber in der Praxis die wirksamste Einzelmaßnahme.

Sind Passwort-Manager trotzdem die richtige Wahl?

Eindeutig ja. Der Bitwarden-Vorfall bestätigt sogar, warum: Selbst bei einem Angriff auf den Anbieter blieben die Tresordaten durch die Zero-Knowledge-Verschlüsselung geschützt. Ein Passwort-Manager ist und bleibt der praktikabelste Weg zu starken, einzigartigen Passwörtern — das BSI empfiehlt den Einsatz im IT-Grundschutz ausdrücklich.

Das eigentliche Risiko sind nicht Passwort-Manager, sondern das, was ohne sie passiert: wiederverwendete Kennwörter, Notizzettel am Bildschirm, „Firma2024!“ als Standardpasswort. Dieses Alltagschaos ist um Größenordnungen gefährlicher als das theoretische Restrisiko eines verschlüsselten Tresors. Wie Sie einen Passwort-Manager im Unternehmen sinnvoll einführen, haben wir in einem eigenen Artikel zusammengefasst.

Nicht der Passwort-Manager ist das Risiko — sondern das, was ohne ihn passiert.

Ergänzen Sie den Manager um Multi-Faktor-Authentifizierung und ein starkes Master-Passwort, schließen Sie die häufigsten Einfallstore. Und wenn Sie wissen möchten, wie sicher Ihre IT insgesamt aufgestellt ist — sprechen Sie uns an. In einem unverbindlichen Sicherheits-Check finden wir es gemeinsam heraus.