Vaultwarden 1.36.0 & NIS2: Self-Hosted Password Management for SMBs

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, one of which is a server-side request forgery that on cloud setups can reach the metadata 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, a deadline runs that German leadership teams cannot ignore in 2026: the NIS2 transposition requires documented security controls by 30 June 2026. Fines up to €10 million or 2 % of global group turnover, plus personal liability for management. Pre-audit findings show missing multi-factor authentication and unmanaged service credentials as two of the three most common gaps — 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
• 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.

The quiet headline: 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 call internal URLs. On a cloud instance this reaches the cloud metadata endpoint (169.254.169.254 on AWS / GCP / Azure, OpenStack et al.), which serves temporary IAM credentials and service account tokens. In practice: a successful SSRF on an AWS-EC2-hosted Vaultwarden instance can be the kick-off for a full cloud account takeover. On-premise the risk is more limited but the device becomes a pivot for internal service discovery.

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.

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 been in force EU-wide since 17 October 2024. In Germany it was transposed into national law in early 2026. 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. The first formal compliance audits start with 30 June 2026 — six to seven weeks out.

The sanctions are not symbolic: up to €10 million or 2 % of global group turnover (depending on entity class), plus personal liability for management (Article 32). 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.

Pre-audit findings from Q4 2025 (collected among others by Passwork and the ENISA threat landscape) name three recurring gaps: missing MFA, over-privileged accounts and unmanaged service credentials — passwords sitting in config files, wiki pages and shared spreadsheets. ENISA additionally documents that 34 % of organisations have a "severe skills gap" in IAM implementation.

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

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 by 30 June 2026? 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