Vaultwarden fully operated on your infrastructure — as a managed service — WZ-IT takes over install, hardening, backups and CVE monitoring on your infrastructure. SSO integration, NIS2-ready documentation and 24/7 monitoring included. Book a kickoff call · More about Vaultwarden · CVE monitoring
On 3 May 2026 the Vaultwarden maintainer team released version 1.36.0 - closing six security advisories, including two CSRF flaws in the SSO login and a blind server-side request forgery in the icon endpoint. In the past three months alone the project has shipped 13 advisories. That is not a sign of weakness; it is a sign of an actively maintained open-source project. But it carries a clear consequence: anyone running Vaultwarden in production needs a working patch process.
In parallel, there is a framework German leadership teams cannot ignore in 2026: Germany's NIS2 transposition act has been in force since 6 December 2025, with no transition period for the security measures. Fines up to EUR 10 million or 2 % of worldwide annual turnover, plus the duty of management to implement and supervise the measures, with liability for culpably caused damage. Multi-factor authentication and managed service credentials are exactly the topics a functioning password stack solves.
This piece sorts out what actually changed in Vaultwarden 1.36.0, what the 2022 LastPass breach still teaches password-manager strategy in 2026, where NIS2 connects concretely — and when Vaultwarden is the right answer for the German Mittelstand and when it isn't.
Table of contents
- What Vaultwarden is and why it suddenly matters
- Six advisories in 1.36.0 — what they actually mean
- Update of 12 October 2026
- The LastPass shock and the lesson for 2026
- NIS2 makes password management a board-level issue
- Vaultwarden vs. Bitwarden Self-Hosted
- When Vaultwarden fits — and when it doesn't
- Self-hosting means owning the responsibility
- How we approach this at WZ-IT
- Further reading
What Vaultwarden is and why it suddenly matters
Vaultwarden is an unofficial, Rust-based re-implementation of the Bitwarden server API. Started in 2018 by Daniel García as "bitwarden_rs", renamed in 2021, today maintained by García plus co-maintainer BlackDex. The project sits at around 59,900 GitHub stars — one of the most successful self-hosted tools on GitHub overall.
Three points make the difference to the official Bitwarden Self-Hosted edition clear:
Footprint. Vaultwarden runs in a single container with about 10 to 50 MB RAM idle. The official Bitwarden Self-Hosted edition consists of multiple containers (API, Identity, Admin, Notifications, Icons, MSSQL) and needs at least 2 GB RAM. For a mid-sized company with 80 to 300 users this is the difference between "runs on a small VM" and "needs a dedicated setup with Microsoft SQL licensing".
Database choice. Vaultwarden speaks SQLite, PostgreSQL and MySQL/MariaDB. The official edition mandates Microsoft SQL Server — in an otherwise Linux/Postgres-based stack an uncomfortable island.
Feature parity without licensing. Vaultwarden ships TOTP, file attachments, organizations, emergency access and Send without per-user fees. In the official Bitwarden Self-Hosted edition those are premium or enterprise features licensed per user per month — at 100 users on the Enterprise plan that is roughly 7,200 USD per year before hardware and operations.
For expectation management: Vaultwarden is not a complete clone. SCIM provisioning, Active Directory directory sync, some complex enterprise policies and a dedicated SOC2 audit are missing. Anyone needing 500+ users with automated lifecycle is better served by the official edition. Anyone running a clean, open-source-based stack for an SMB that speaks to all official Bitwarden clients (browser, mobile, desktop, CLI) unmodified is exactly where Vaultwarden shines.
Six advisories in 1.36.0 — what they actually mean
On 3 May 2026 the maintainer team released 1.36.0 with six new GHSA advisories. At the time of publication the technical details are still under embargo (until CVE assignment), but the classification is clear:
Three SSO advisories on login. GHSA-pfp2-jhgq-6hg5 and GHSA-w6h6-8r66-hcv7 cover cross-site request forgery in the SSO login flow. Concretely: an attacker can sneak a manipulated login request to an authenticated victim, for instance by getting the victim onto an attacker-controlled page in the same browser session as the Vaultwarden login. Risk class: account-takeover vector, depending on the specific SSO flow.
Two SSO binding advisories. GHSA-j4j8-gpvj-7fqr and GHSA-6x5c-84vm-5j56 cover the binding of existing users to SSO identities. Anyone with an existing Vaultwarden account who logs in via SSO for the first time runs through a binding process — and exactly this process had bugs that under an unfavourable configuration allow account takeover.
User and organization enumeration. GHSA-hxqh-ff5p-wfr3. More reconnaissance than direct attack: attackers can probe whether a specific account or organization exists. Direct damage low, but the information feeds targeted phishing.
Blind SSRF via the icon endpoint. GHSA-72vh-x5jq-m82g. Vaultwarden fetches the favicon for a stored URL via a server-side HTTP request. Manipulating that request can force the server to query internal IP addresses. According to the advisory, Vaultwarden only returns parsed favicons, not response bodies. The flaw therefore allows blind discovery of the internal network via timing and size differences, but no reading of data such as cloud metadata credentials (CVSS 5.8).
The SSO flaws hit particularly hard because they touch exactly the configurations enterprise customers run: Authentik, Keycloak, Microsoft Entra ID, Google Workspace or Okta as the central identity provider via OIDC. Anyone who has set up SSO in the past months should not treat 1.36.0 as a routine update.
Also worth context: this isn't the first patch of this class. Between February and May 2026 Vaultwarden published 13 advisories:
- 1.35.3 (10 Feb 2026) — Cross-collection access (GHSA-h265-g7rm-h337)
- 1.35.4 (23 Feb 2026) — three advisories on cipher access and manager permissions
- 1.35.5 (12 Apr 2026) — three advisories: unconfirmed owners could purge org vaults, cross-org group binding, refresh-token invalidation
- 1.35.6 (12 Apr 2026) — hotfix for a regression in 1.35.5 that completely broke MFA remember and recovery tokens
- 1.35.7 / 1.35.8 — minor bug fixes
- 1.36.0 (3 May 2026) — the current six advisories plus item archiving
That is normal for an actively maintained open-source project. But it also means: anyone running Vaultwarden and not patching within days is, at any given moment, operating a known vulnerability. Patch management is not a nice-to-have here, it is a precondition for operating.
Update of 12 October 2026
The situation has moved on since this post was published:
- CVE IDs assigned. Four of the six advisories from 1.36.0 have been public since 19 May 2026: CVE-2026-47158 (CSRF in the SSO flow, CVSS 8.3), CVE-2026-47164 (SSO linking of an existing account to an attacker-controlled IdP identity, CVSS 7.7), CVE-2026-47160 (SSRF via decimal, hex and octal IP notation, CVSS 5.8) and CVE-2026-47159 (organization enumeration in SSO discovery). The SSO flaws are therefore rated higher than the SSRF.
- Correction of 12 October 2026. An earlier version described the SSRF from 1.36.0 as a possible path to cloud metadata credentials and cloud account takeover. According to the advisory it is a blind SSRF that only allows discovery of the internal network. In addition, the registration deadline under Section 33 BSIG is three months after an entity qualifies; March 2026 applied only to entities covered when the act came into force.
- SSRF fix hardened again. Vaultwarden 1.37.0 from 24 July 2026 closes two bypasses of the SSRF protection in the icon endpoint (GHSA-hw4g-2v3f-74x5, GHSA-vh5m-fc9v-m84g) plus further medium-severity flaws, including cross-organization cipher access.
- Current version 1.37.4. Vaultwarden 1.37.4 from 5 October 2026 fixes seven more advisories, including a high-severity flaw in organization member revocation (GHSA-69q9-v8p6-xvx3, CVSS 8.1). Anyone still on 1.36.x should update straight to 1.37.4.
As of 12 October 2026 there is no Vaultwarden entry in the CISA KEV catalog.
The LastPass shock and the lesson for 2026
In August 2022 the LastPass developer environment was compromised — via a stolen developer account. In November 2022 the second wave came: a DevOps engineer ran a Plex server at home, an exploit came in via the unpatched Plex instance onto the personal laptop, the personal laptop had access to the production AWS account. The access went undetected for 79 days. In the end the entire customer vault backups were stolen from cloud storage — including the unencrypted metadata sections (vault URLs, hostnames).
Three lessons from the incident that remain relevant for any password-manager strategy in 2026:
A central cloud provider is a central honeypot. LastPass had over 33 million registered users and 100,000+ business customers. A single successful breach put all of them in a risk position. Self-hosting distributes the risk: an attacker has to break each instance individually instead of opening a database with millions of vaults.
Encrypted vaults are not "safe". AES-256 protects only as long as the master password is strong and the attacker lacks offline cracking resources. Neither is guaranteed. From March 2025, several confirmed six-figure crypto thefts were traced directly to LastPass vaults stolen in 2022 — attackers had years to crack master passwords and used the unencrypted URL metadata to identify which vaults held crypto.
Disclosure delays cost more trust than the incident itself. LastPass communicated incrementally and downplayed; each correction eroded more trust. The message for users was clear: a cloud password manager offloads responsibility — but in a crisis you depend on the provider's communications and crisis management.
Self-hosting doesn't solve the cloud-concentration problem for free — you trade central vendor risk for operational ownership. What self-hosting does provide: data sovereignty, an audit trail not sitting in the reporting backend of a US provider, and the ability to know yourself what was compromised when something goes wrong.
NIS2 makes password management a board-level issue
The NIS2 directive has applied EU-wide since 18 October 2024. In Germany the NIS2 transposition act has been in force since 6 December 2025. Around 30,000 German companies are directly affected - as "essential" or "important" entities in sectors like energy, transport, banking, healthcare, drinking water, digital infrastructure, food, research and more. There is no transition period for the security measures; entities must register with the BSI no later than three months after they first qualify as an affected entity (Section 33 BSIG). For entities already covered when the act came into force, the deadline ran until early March 2026.
The sanctions are not symbolic: up to €10 million or 2 % of global group turnover (depending on entity class), plus the duty of management to implement and supervise the risk management measures, with liability for culpably caused damage (Section 38 BSIG, Article 20 of the NIS2 directive). In severe cases temporary removal from management roles.
NIS2 does not name password managers. But Article 21(2) lists ten measures to implement "appropriately and proportionately", and several of them are practically unenforceable without a structured credential stack:
- (d) Supply-chain security — including the question of where IAM and credential data is processed. Data sovereignty here is not optional; it's a concrete audit question.
- (g) Basic cyber hygiene — structured password management is part of any ENISA definition.
- (h) Cryptography and encryption — end-to-end vault encryption is the standard auditors look for.
- (i) Personnel security, access control concepts — RBAC on collections, granular permissions, audit logs.
- (j) Multi-factor authentication — explicitly named as a technical mandatory measure.
Typical gaps in practice: missing MFA, over-privileged accounts and unmanaged service credentials, i.e. passwords sitting in config files, wiki pages and shared spreadsheets.
What a NIS2-aligned password stack has to deliver — and what Vaultwarden covers:
- ✅ Central management with RBAC (organizations, collections, groups)
- ✅ MFA enforceable (TOTP, WebAuthn/FIDO2, YubiKey, Duo)
- ✅ Audit logs in the admin panel
- ✅ Encryption at rest (AES-256, Argon2id KDF since Bitwarden client v2024) and in transit (TLS)
- ✅ Data sovereignty through self-hosting on your own infrastructure in the EU
- ✅ Auditability via backup and patch logs
Combined with the NIS2 context from the Linux kernel piece and the VPN modernisation piece, the overall picture emerges: NIS2 forces structural modernisation at three points simultaneously — patch management, network access, credential management. Not three independent projects, but one connected operations model.
Vaultwarden vs. Bitwarden Self-Hosted
| Criterion | Vaultwarden | Bitwarden Self-Hosted (official) |
|---|---|---|
| Implementation | Rust | C# / .NET |
| RAM (idle) | ~10–50 MB | 2+ GB |
| Containers | 1 | multiple (API, Identity, Admin, Notifications, Icons, SQL) |
| Database | SQLite, PostgreSQL, MySQL | Microsoft SQL Server (mandatory) |
| Licence | AGPL-3.0 | Bitwarden License + premium EE licences |
| Premium features | all free (TOTP, Send, attachments, orgs) | Enterprise licence, ~6 USD/user/month |
| SCIM provisioning | no | yes |
| Directory sync (AD/LDAP) | no | yes |
| SOC2 audit | no | yes |
| Vendor SLA support | no | yes (Bitwarden Inc.) |
| Audit logs | yes (admin panel) | yes (more extensive) |
| MFA | TOTP, WebAuthn, YubiKey, Duo | identical |
| SSO (OIDC) | yes (since 1.35.0) | yes |
| Setup time | ~5–15 min via Docker | several hours, MSSQL configuration |
| Code base size | small, easy to audit | large |
| Memory safety | ✅ (Rust) | C# managed |
| Scale range | SMB up to ~200 users | unlimited |
Both speak the same API and use the same official clients — switching between them is vault-compatible and an export/import takes about an hour.
When Vaultwarden fits — and when it doesn't
Vaultwarden is the right choice when:
- 5 to 200 users need to be covered (typical Mittelstand setup)
- the stack is Linux/container-based and Microsoft SQL Server doesn't fit
- premium features (attachments, TOTP, Send) without per-user licences matter
- self-hosting on Hetzner, netcup, Proxmox or on-premise is the goal
- an existing open-source IAM system (Authentik, Keycloak, Zitadel) serves as the SSO source
- cost transparency outweighs vendor-supported SLAs
Bitwarden Self-Hosted (official) becomes the right choice when:
- SCIM provisioning for automated user lifecycle is required
- Active Directory directory sync is mandatory
- the organisation depends on vendor-backed SLA support
- regulators require a dedicated SOC2 audit (typical in financial services)
- scaling beyond 500 to 1000 users is on the roadmap
What Vaultwarden honestly is not:
- Not a complete Bitwarden clone — some enterprise org policies and SCIM are missing
- No formal third-party security audit
- No dedicated commercial vendor — the maintainer state hangs on the open-source team around Daniel García and BlackDex
- No ready-made compliance report templates for NIS2 / ISO 27001 — those have to be assembled
This caveat belongs in every honest Vaultwarden pitch: self-hosting trades vendor risk for operational ownership. That isn't an argument against Vaultwarden — but it is an argument for an organised operations strategy.
Self-hosting means owning the responsibility
A production Vaultwarden instance needs five building blocks, without which the system carries more risk than solution:
1. Patch management. At 13 advisories in three months, a weekly patch check is the minimum. Ideally automated builds that produce a new image on every tag release and roll it out automatically.
2. Reverse proxy with TLS 1.3 and hardening. Exposing Vaultwarden directly on port 80 is not an option. Nginx or Caddy in front, TLS 1.3 with a modern cipher suite, HSTS enabled, optional geo-blocking and rate-limiting on the login endpoints.
3. MFA enforcement. The admin panel can require MFA as a login precondition for all organization members. Default settings that don't do this are a direct gap in a NIS2 audit.
4. Backup strategy for vault data. A lost password vault is a business disaster. Standard: 3-2-1-1-0 like for any critical dataset — three copies, two media, one offsite, one immutable, zero verify failures. More detail in the PBS offsite piece. Important: vault data plus server-side encryption key plus attachment storage all belong in the backup.
5. SSO integration with a structured identity provider. The Vaultwarden login as an isolated account pool is a dead end — offboarding gets forgotten. SSO via Authentik, Keycloak or Zitadel ensures that a deactivated employee immediately loses access.
For heavily regulated environments, add: an egress filter that allows outbound connections from the Vaultwarden instance only to defined targets (update servers, your own registries). That closes the SSRF path of 1.36.0 before the patch is applied — an architectural measure that survives individual CVEs.
How we approach this at WZ-IT
We run Vaultwarden as part of our managed open-source portfolio in three stages.
Stage 1 — Setup and hardening. Vaultwarden on your infrastructure (typically Hetzner Cloud, netcup root server, or your own Proxmox cluster), with reverse proxy, TLS 1.3, rate-limiting on auth endpoints, MFA enforcement and egress filtering. Note on licensing: because of Bitwarden trademarks we render the offering as "fully operated on your infrastructure" — Vaultwarden remains AGPL-3.0, API compatibility with Bitwarden clients is given, and we respect Bitwarden Inc.'s commercial trademark scope. A vendor-disclaimer-ready architecture document is part of the engagement.
Stage 2 — CVE monitoring and patch management. Our managed operations service follows GitHub security advisories for dani-garcia/vaultwarden daily, plus the general NVD/CISA-KEV/BSI feeds. The six advisories in 1.36.0 would have been installed at our customers within hours — and the 13+ advisories of the past three months are documented in the compliance report with patch timestamps.
Stage 3 — Backup, SSO integration and compliance reporting. 3-2-1-1-0 backup strategy (see the PBS offsite piece), SSO integration with your identity system (or building a dedicated Authentik or Keycloak instance in the same stack), and monthly compliance reporting for NIS2 audits. Anyone classified as an essential or important entity under NIS2 and required to present documented risk management gets the necessary evidence on demand.
On cost: an SMB with 100 users pays around 7,200 USD per year for a Bitwarden Enterprise licence before hardware and operations. A Vaultwarden instance fully operated by us, with hardening, patch management, SSO and compliance reporting, costs significantly less — and delivers the operations substance that NIS2 audits expect.
Further reading
- Vaultwarden — Fully operated on your infrastructure — service overview and scope
- CVE monitoring & vulnerability scanner — the central service behind structured patch response
- Authentik and Keycloak — identity providers for SSO integration
- Hetzner hosting — EU infrastructure for GDPR / NIS2 setups
- Linux kernel vulnerabilities 2026 — patch management at board level — the NIS2 context in detail
- CVE monitoring for self-hosted software — how structured response to vulnerabilities works
- Cisco ASA, ArcaneDoor & CVE-2025-20362 — edge devices and the same NIS2 mechanism on the network side
- Bleeding Llama (CVE-2026-7482) — self-hosted AI with the same operations question
- PBS offsite pull architecture — backup strategy that also covers vault data
Are you already running Vaultwarden or considering self-hosted password management and need to deliver NIS2 evidence? We review your current architecture at no cost: patch status, hardening posture, backup strategy, SSO integration, audit readiness. Output: a concrete recommendation with priorities, or direct takeover as a managed service.
Book a free Vaultwarden architecture review · More about Vaultwarden · CVE monitoring
