Vaultwarden 1.36.0 & NIS2: Self-Hosted Passwort-Management für KMU

Vaultwarden vollständig betrieben — als Managed Service — WZ-IT übernimmt Installation, Hardening, Backups und CVE-Monitoring auf Ihrer Infrastruktur. SSO-Anbindung, NIS2-konforme Dokumentation und 24/7-Monitoring inklusive. Erstgespräch buchen · Mehr zu Vaultwarden · CVE-Monitoring

Am 3. Mai 2026 hat das Vaultwarden-Maintainer-Team Version 1.36.0 veröffentlicht — und damit sechs Security-Advisories geschlossen, eines davon eine Server-Side-Request-Forgery, die in Cloud-Setups bis zum Metadata-Endpoint reichen kann. Allein in den letzten drei Monaten hat das Projekt 13 Advisories veröffentlicht. Das ist kein Schwächezeichen, sondern ein Reifezeichen aktiver Open-Source-Software — bringt aber eine klare Konsequenz mit: Wer Vaultwarden im Unternehmen einsetzt, braucht ein funktionierendes Patch-Management.

Parallel läuft eine Frist, die deutsche Geschäftsführungen 2026 nicht ignorieren können: Die NIS2-Umsetzung verlangt bis 30. Juni 2026 den Nachweis dokumentierter Sicherheitsmaßnahmen. Bußgelder bis zu 10 Millionen Euro oder zwei Prozent des weltweiten Konzernumsatzes, plus persönliche Haftung der Geschäftsleitung. Pre-Audit-Befunde zeigen: fehlende Multi-Faktor-Authentifizierung und unverwaltete Service-Credentials gehören zu den drei häufigsten Mängeln. Genau die Themen, für die ein funktionierender Passwort-Stack die Antwort ist.

Dieser Beitrag ordnet ein, was bei Vaultwarden 1.36.0 wirklich passiert ist, was der LastPass-Breach von 2022 für Passwort-Manager-Strategie weiterhin lehrt, wo NIS2 konkret andockt — und wann Vaultwarden die richtige Antwort für den Mittelstand ist und wann eben nicht.

Inhaltsverzeichnis

• Was Vaultwarden ist und warum es plötzlich relevant wird
• Sechs Lücken in 1.36.0 — und was sie konkret bedeuten
• Der LastPass-Schock und die Lehre für 2026
• NIS2 macht Passwort-Management zur Chefsache
• Vaultwarden vs. Bitwarden Self-Hosted
• Wann Vaultwarden passt — und wann nicht
• Self-Hosting heißt Verantwortung übernehmen
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Was Vaultwarden ist und warum es plötzlich relevant wird

Vaultwarden ist eine in Rust geschriebene, inoffizielle Re-Implementierung der Bitwarden-Server-API. Ursprünglich 2018 von Daniel García als "bitwarden_rs" gestartet, 2021 umbenannt, heute gepflegt von García plus dem Co-Maintainer BlackDex. Das Projekt liegt bei rund 59.900 GitHub-Stars und ist damit eines der erfolgreichsten Self-Hosted-Tools auf GitHub überhaupt.

Drei Punkte machen den Unterschied zur offiziellen Bitwarden-Self-Hosted-Variante deutlich:

Footprint. Vaultwarden läuft in einem einzelnen Container mit rund 10 bis 50 MB RAM im Leerlauf. Die offizielle Bitwarden-Self-Hosted-Edition besteht aus mehreren Containern (API, Identity, Admin, Notifications, Icons, MSSQL) und braucht mindestens 2 GB RAM. Für einen Mittelständler mit 80 bis 300 Nutzern ist das ein Unterschied zwischen "läuft auf einer schmalen VM" und "braucht ein dediziertes Setup mit Microsoft-SQL-Lizenz".

Datenbank-Wahl. Vaultwarden spricht SQLite, PostgreSQL und MySQL/MariaDB. Die offizielle Edition setzt Microsoft SQL Server voraus — was in einem ansonsten Linux-/Postgres-basierten Stack eine ungemütliche Insellösung erzeugt.

Feature-Parität ohne Lizenz. Vaultwarden stellt TOTP, File Attachments, Organizations, Emergency Access und Send ohne Per-User-Gebühren bereit. Bei der offiziellen Bitwarden-Self-Hosted-Variante sind das Premium- bzw. Enterprise-Features, die pro Nutzer und Monat lizenziert werden — bei 100 Nutzern Enterprise sind das rund 7.200 USD pro Jahr vor Hardware und Operations.

Klartext für Erwartungs-Management: Vaultwarden ist keine vollständige Kopie. SCIM-Provisioning, Directory-Sync mit Active Directory, einige komplexe Enterprise-Policies und ein dediziertes SOC2-Audit fehlen. Wer 500+ Nutzer mit automatisiertem Lifecycle braucht, ist mit der offiziellen Edition besser bedient. Wer als KMU einen sauberen, Open-Source-basierten Stack will, der mit allen offiziellen Bitwarden-Clients (Browser, Mobile, Desktop, CLI) ohne Anpassung spricht, ist bei Vaultwarden goldrichtig.

Sechs Lücken in 1.36.0 — und was sie konkret bedeuten

Das Maintainer-Team hat am 3. Mai 2026 mit Release 1.36.0 sechs neue GHSA-Advisories veröffentlicht. Zum Veröffentlichungszeitpunkt sind die Details noch unter Verschluss (Embargo bis CVE-Vergabe), die Kategorisierung ist aber klar:

Drei SSO-Lücken auf Login-Ebene. GHSA-pfp2-jhgq-6hg5 und GHSA-w6h6-8r66-hcv7 betreffen Cross-Site-Request-Forgery im SSO-Login-Flow. Konkret: ein Angreifer kann einem authentifizierten Opfer eine manipulierte Login-Anfrage unterschieben, etwa indem das Opfer auf einer fremden Seite gelandet ist und im selben Browser-Session Vaultwarden eingeloggt war. Risiko-Klasse: Account-Übernahme-Vektor, abhängig vom konkreten SSO-Flow.

Zwei SSO-Binding-Lücken. GHSA-j4j8-gpvj-7fqr und GHSA-6x5c-84vm-5j56 betreffen das Binding bestehender Nutzer an SSO-Identitäten. Wer bereits einen Vaultwarden-Account hat und sich später erstmals via SSO anmeldet, durchläuft einen Binding-Prozess — und genau dieser Prozess hatte Lücken, die in einer ungünstigen Konfiguration eine Account-Übernahme erlauben.

User- und Organization-Enumeration. GHSA-hxqh-ff5p-wfr3. Eher Aufklärungsklasse: Angreifer können prüfen, ob ein bestimmter Account oder eine bestimmte Organization existiert. Direkter Schaden gering, aber die Information füttert gezielte Phishing-Kampagnen.

Die heimliche Königsdisziplin: SSRF via Icon-Endpoint. GHSA-72vh-x5jq-m82g. Vaultwarden lädt für Vault-Einträge das Favicon der hinterlegten URL — über einen serverseitigen HTTP-Request. Wer diesen Request manipuliert, kann den Server zwingen, intern erreichbare URLs aufzurufen. Auf einer Cloud-Instanz reicht das bis zum Cloud-Metadata-Endpoint (169.254.169.254 bei AWS / GCP / Azure, OpenStack et al.), der temporäre IAM-Credentials und Service-Account-Tokens ausgibt. Praktisch: ein erfolgreicher SSRF auf einer AWS-EC2-gehosteten Vaultwarden-Instanz kann der Auftakt zu einer vollständigen Cloud-Kontoübernahme sein. On-Prem ist das Risiko begrenzter, aber das Gerät wird zum Pivot für interne Service-Discovery.

Die SSO-Lücken treffen besonders bitter, weil sie genau die Setups betreffen, die Enterprise-Kunden haben: Authentik, Keycloak, Microsoft Entra ID, Google Workspace oder Okta als zentralen Identity-Provider via OIDC. Wer in den letzten Monaten SSO eingerichtet hat, sollte 1.36.0 nicht als Routine-Update behandeln.

Auch wichtig zur Einordnung: das ist nicht der erste Patch dieser Art. Allein zwischen Februar und Mai 2026 hat Vaultwarden 13 Advisories veröffentlicht:

• 1.35.3 (10.02.2026) — Cross-Collection-Access (GHSA-h265-g7rm-h337)
• 1.35.4 (23.02.2026) — drei Advisories zu Cipher-Access und Manager-Permissions
• 1.35.5 (12.04.2026) — drei Advisories: unbestätigte Owner konnten Org-Vaults purgen, Cross-Org-Group-Binding, Refresh-Token-Invalidation
• 1.35.6 (12.04.2026) — Hotfix für eine Regression in 1.35.5, die MFA-Remember- und Recovery-Tokens komplett brach
• 1.35.7 / 1.35.8 — kleinere Bugfixes
• 1.36.0 (03.05.2026) — die sechs aktuellen Advisories plus Item-Archivierungs-Feature

Das ist normal für ein aktives Open-Source-Projekt. Es bedeutet aber auch: Wer Vaultwarden einsetzt und nicht binnen Tagen patcht, betreibt zu jedem gegebenen Zeitpunkt eine bekannte Lücke. Patch-Management ist hier kein Nice-to-have, sondern Betriebsvoraussetzung.

Der LastPass-Schock und die Lehre für 2026

Im August 2022 wurde das Developer-Environment von LastPass kompromittiert — über ein gestohlenes Entwickler-Konto. Im November 2022 folgte die zweite Welle: ein DevOps-Engineer hatte zuhause einen Plex-Server laufen, ein Exploit kam über die ungepatchte Plex-Instanz auf den privaten Laptop, der private Laptop hatte Zugriff aufs Produktions-AWS-Konto. 79 Tage war der Zugriff unentdeckt. Am Ende waren die kompletten Customer Vault Backups aus dem Cloud-Storage gestohlen — inklusive der unverschlüsselten Metadaten-Anteile (Vault-URLs, Hostnamen).

Drei Lehren aus dem Vorgang, die für jede Passwort-Manager-Strategie 2026 relevant bleiben:

Ein zentraler Cloud-Anbieter ist ein zentraler Honeypot. LastPass hatte über 33 Millionen registrierte Nutzer und 100.000+ Business-Kunden. Ein einziger erfolgreicher Angriff hat alle in eine Risiko-Position gebracht. Self-Hosting verteilt das Risiko: ein Angreifer muss jede Instanz einzeln knacken, statt eine Datenbank mit Millionen Vaults zu öffnen.

Verschlüsselte Vaults sind nicht "sicher". AES-256 schützt nur, solange das Master-Passwort stark ist und der Angreifer keine Offline-Cracking-Ressourcen hat. Beides ist nicht garantiert. Ab März 2025 wurden mehrere Krypto-Diebstähle im sechsstelligen Bereich direkt auf 2022 gestohlene LastPass-Vaults zurückgeführt — die Angreifer hatten Jahre, um Master-Passwörter zu cracken, und nutzten die unverschlüsselten URL-Metadaten, um zu erkennen, welche Vaults Krypto-Bestände enthielten.

Disclosure-Verschleppung kostet mehr Vertrauen als der Vorfall selbst. LastPass kommunizierte schrittweise und untertreibend; jede Korrektur erodierte mehr Vertrauen. Die Nachricht für Anwender war eindeutig: ein Cloud-Passwort-Manager gibt Verantwortung ab — aber im Krisenfall hängt man am Kommunikations- und Krisenmanagement des Anbieters.

Self-Hosting löst das Cloud-Konzentrationsproblem nicht für umsonst — man tauscht zentrales Anbieterrisiko gegen eigene Betriebsverantwortung. Was Self-Hosting aber liefert: Datensouveränität, eine Audit-Trail, die nicht im Reporting-Backend eines US-Anbieters liegt, und die Möglichkeit, im Vorfall selbst zu wissen, was kompromittiert ist.

NIS2 macht Passwort-Management zur Chefsache

Die NIS2-Richtlinie ist seit dem 17. Oktober 2024 EU-weit in Kraft. In Deutschland wurde sie Anfang 2026 in nationales Recht überführt. Rund 30.000 deutsche Unternehmen sind direkt betroffen — als "wesentliche" oder "wichtige" Einrichtungen in Sektoren wie Energie, Verkehr, Bankwesen, Gesundheit, Trinkwasser, digitaler Infrastruktur, Lebensmittel, Forschung und mehr. Die ersten formellen Compliance-Audits beginnen mit dem 30. Juni 2026 — also in sechs bis sieben Wochen.

Die Sanktionen sind kein Symbol: bis zu 10 Millionen Euro oder zwei Prozent des weltweiten Konzernumsatzes (je nach Klasse der Einrichtung), plus persönliche Haftung der Geschäftsleitung (Artikel 32). In schweren Fällen droht der temporäre Ausschluss von Führungsaufgaben.

Passwort-Manager werden in NIS2 nicht namentlich genannt. Aber Artikel 21 Absatz 2 listet zehn Maßnahmen, die "geeignet und verhältnismäßig" umzusetzen sind, und ohne strukturierten Credential-Stack sind mehrere davon praktisch unerfüllbar:

• (d) Sicherheit der Lieferkette — inklusive der Frage, wo IAM-/Credential-Daten verarbeitet werden. Datensouveränität ist hier nicht Kür, sondern eine konkrete Audit-Frage.
• (g) Grundlegende Cyberhygiene — strukturiertes Passwort-Management gehört in jede ENISA-Definition davon.
• (h) Kryptografie und Verschlüsselung — End-to-End-Vault-Verschlüsselung ist der Standard, gegen den auditiert wird.
• (i) Sicherheit des Personals, Zugangskontrollkonzepte — RBAC auf Collections, granulare Berechtigungen, Audit-Logs.
• (j) Multi-Faktor-Authentifizierung — als technische Pflicht-Anforderung explizit benannt.

Die Pre-Audit-Befunde aus Q4 2025 (zusammengetragen unter anderem von Passwork und der ENISA-Threat-Landscape) nennen drei wiederkehrende Mängel: fehlende MFA, überprivilegierte Accounts und unverwaltete Service-Credentials — also Passwörter, die in Konfigurationsdateien, Wiki-Artikeln oder geteilten Spreadsheet liegen. ENISA dokumentiert zusätzlich, dass 34 Prozent der Organisationen einen "schwerwiegenden Fachkräftemangel" bei IAM-Implementierung haben.

Was ein NIS2-konformer Passwort-Stack liefern muss — und was Vaultwarden bedient:

• ✅ Zentrale Verwaltung mit RBAC (Organizations, Collections, Groups)
• ✅ MFA durchsetzbar (TOTP, WebAuthn/FIDO2, YubiKey, Duo)
• ✅ Audit-Logs im Admin-Panel
• ✅ Verschlüsselung at-rest (AES-256, Argon2id KDF seit Bitwarden-Client v2024) und in-transit (TLS)
• ✅ Datensouveränität durch Self-Hosting auf eigener Infrastruktur in der EU
• ✅ Nachweisbarkeit über Backup- und Patch-Logs

Verlinkt mit dem NIS2-Kontext aus dem Linux-Kernel-Beitrag und dem VPN-Modernisierungs-Beitrag entsteht das Gesamtbild: NIS2 zwingt zur strukturellen Modernisierung an drei Stellen gleichzeitig — Patch-Management, Netzwerkzugang, Credential-Management. Das sind nicht drei unabhängige Projekte, sondern ein zusammenhängendes Operations-Modell.

Vaultwarden vs. Bitwarden Self-Hosted

Beide nutzen dieselbe API und sprechen mit denselben offiziellen Clients — der Wechsel zwischen den beiden ist im Vault-Format kompatibel und mit Export/Import in einer Stunde gemacht.

Wann Vaultwarden passt — und wann nicht

Vaultwarden ist die richtige Wahl, wenn:

• 5 bis 200 Nutzer abgedeckt werden müssen (typisches Mittelstands-Setup)
• der Stack Linux/Container-basiert ist und Microsoft SQL Server keinen Platz hat
• Premium-Features (Attachments, TOTP, Send) ohne Per-User-Lizenz gefragt sind
• Self-Hosting auf Hetzner, netcup, Proxmox oder On-Premise das Ziel ist
• ein vorhandenes Open-Source-IAM-System (Authentik, Keycloak, Zitadel) als SSO-Quelle dienen soll
• Kostentransparenz wichtiger ist als Vendor-Support-SLAs

Bitwarden Self-Hosted (offiziell) wird sinnvoll, wenn:

• SCIM-Provisioning für automatisches User-Lifecycle-Management gebraucht wird
• Directory-Sync mit Active Directory zwingend ist
• die Organisation auf vendor-getragenen SLA-Support angewiesen ist
• regulatorisch ein dediziertes SOC2-Audit verlangt wird (typisch im Finanzsektor)
• die Skalierung über 500 bis 1000 Nutzer hinausgeht

Was Vaultwarden ehrlicherweise nicht ist:

• Kein vollständiger Bitwarden-Klon — manche Enterprise-Org-Policies und SCIM fehlen
• Kein formelles Security-Audit durch eine dritte Partei
• Kein dedizierter kommerzieller Vendor — der Maintainer-Stand hängt am Open-Source-Team rund um Daniel García und BlackDex
• Keine fertigen Compliance-Report-Templates für NIS2/ISO 27001 — die müssen selbst zusammengesetzt werden

Dieser Hinweis gehört zu jedem ehrlichen Vaultwarden-Pitch: Self-Hosting tauscht Vendor-Risiko gegen Operations-Verantwortung. Das ist kein Argument gegen Vaultwarden — aber es ist ein Argument für eine geordnete Betriebsstrategie.

Self-Hosting heißt Verantwortung übernehmen

Eine produktive Vaultwarden-Instanz braucht fünf Bausteine, ohne die das System mehr Risiko als Lösung ist:

1. Patch-Management. Bei 13 Advisories in drei Monaten ist ein wöchentlicher Patch-Check Minimum. Idealerweise automatisierte Builds, die bei jedem Tag-Release ein neues Image bauen und automatisch einspielen.

2. Reverse Proxy mit TLS 1.3 und Hardening. Vaultwarden auf Port 80 direkt zu exponieren ist keine Option. Nginx oder Caddy davorsetzen, TLS 1.3 mit modernem Cipher-Set, HSTS aktivieren, optional Geo-Blocking und Rate-Limiting auf Login-Endpoints.

3. MFA-Pflicht. Im Admin-Panel kann MFA als Login-Voraussetzung für alle Organization-Mitglieder erzwungen werden. Default-Einstellungen, die das nicht tun, sind in NIS2-Audits ein direkter Mangel.

4. Backup-Strategie für Vault-Daten. Ein verlorener Passwort-Vault ist ein Geschäftsdesaster. Standard: 3-2-1-1-0-Strategie wie für jeden anderen kritischen Datensatz — drei Kopien, zwei Medien, eine offsite, eine immutable, null Verify-Fehler. Mehr Details dazu im PBS-Offsite-Beitrag. Wichtig: Vault-Daten plus Server-seitiger Encryption-Key plus Attachment-Storage gehören ins Backup.

5. SSO-Anbindung an einen geordneten Identity-Provider. Der Vaultwarden-Login als isolierter Account-Pool ist eine Sackgasse — bei Offboarding wird vergessen. SSO über Authentik, Keycloak oder Zitadel sorgt dafür, dass ein deaktivierter Mitarbeiter sofort den Zugriff verliert.

Ergänzend, für stark regulierte Umgebungen: ein Egress-Filter, der ausgehende Verbindungen von der Vaultwarden-Instanz nur zu definierten Zielen (Update-Server, eigene Registries) erlaubt. Genau das schließt im Bedarfsfall den SSRF-Pfad von 1.36.0, bevor der Patch eingespielt wurde — eine Architektur-Maßnahme, die einzelne CVEs überlebt.

Unser Vorgehen bei WZ-IT

Wir betreiben Vaultwarden im Rahmen unseres Managed Open-Source-Portfolios in drei Stufen.

Stufe 1 — Setup und Hardening. Vaultwarden auf Ihrer Infrastruktur (typisch: Hetzner Cloud, netcup Root Server, oder Ihr eigener Proxmox-Cluster), mit Reverse Proxy, TLS 1.3, Rate-Limiting auf Auth-Endpoints, MFA-Pflicht und Egress-Filtering. Hinweis zur Lizenz: Wegen der Bitwarden-Trademarks rendern wir das Angebot als "Vollständig betrieben auf Ihrer Infrastruktur" — Vaultwarden bleibt unter AGPL-3.0, die API-Kompatibilität zu Bitwarden-Clients ist gegeben, die kommerzielle Trademark-Hoheit von Bitwarden Inc. respektieren wir. Eine vendor-disclaimer-fertige Architektur-Dokumentation gehört zum Auftrag.

Stufe 2 — CVE-Monitoring und Patch-Management. Über unseren Managed-Operations-Service verfolgen wir täglich GitHub Security Advisories für dani-garcia/vaultwarden plus die generellen NVD-/CISA-KEV-/BSI-Feeds. Die sechs Advisories aus 1.36.0 wären bei unseren Kunden innerhalb von Stunden eingespielt gewesen — und die 13+ Advisories der letzten drei Monate sind dokumentiert mit dem Patch-Zeitpunkt im Compliance-Report.

Stufe 3 — Backup, SSO-Integration und Compliance-Reporting. Backup-Strategie nach 3-2-1-1-0 (siehe PBS-Offsite-Beitrag), SSO-Anbindung an Ihr Identity-System (oder Aufbau einer eigenen Authentik- oder Keycloak-Instanz im selben Stack), und monatliches Compliance-Reporting für NIS2-Audits. Wer als wesentliche oder wichtige Einrichtung nach NIS2 ein dokumentiertes Risikomanagement vorlegen muss, bekommt von uns die nötigen Belege auf Knopfdruck.

Konkret in der Kostenfrage: ein KMU mit 100 Nutzern zahlt für eine Bitwarden-Enterprise-Lizenz rund 7.200 USD pro Jahr vor Hardware/Operations. Eine bei uns vollständig betriebene Vaultwarden-Instanz mit Hardening, Patch-Management, SSO und Compliance-Reporting kostet deutlich weniger — und liefert die Operations-Substanz, die NIS2-Audits erwarten.

Weiterführende Guides

• Vaultwarden — Vollständiger Betrieb auf Ihrer Infrastruktur — Service-Übersicht und Leistungsumfang
• CVE-Monitoring & Schwachstellen-Scanner — der zentrale Service hinter strukturierter Patch-Reaktion
• Authentik und Keycloak — Identity-Provider für SSO-Anbindung
• Hetzner Hosting — EU-Infrastruktur für DSGVO-/NIS2-Setups
• Linux-Kernel-Schwachstellen 2026 — Patch-Management Chefsache — der NIS2-Kontext im Detail
• CVE-Monitoring für Self-Hosted Software — wie strukturelle Reaktion auf Schwachstellen funktioniert
• Cisco ASA, ArcaneDoor & CVE-2025-20362 — Edge-Devices und der gleiche NIS2-Mechanismus auf der Netzwerk-Seite
• Bleeding Llama (CVE-2026-7482) — Self-Hosted AI mit derselben Operations-Frage
• PBS Offsite-Pull-Architektur — Backup-Strategie auch für Vault-Daten

Sie betreiben Vaultwarden bereits oder denken über Self-Hosted Passwort-Management nach — und müssen bis 30. Juni 2026 NIS2-Nachweise vorlegen? Wir prüfen Ihre aktuelle Architektur kostenfrei: Patch-Stand, Hardening-Posture, Backup-Strategie, SSO-Integration, Audit-Tauglichkeit. Output: konkrete Empfehlung mit Priorisierung, oder direkte Übernahme als Managed Service.

Kostenloses Vaultwarden-Architektur-Review buchen · Mehr zu Vaultwarden · CVE-Monitoring