Vaultwarden is a self-hosted server that works with the Bitwarden apps. If your team runs it to share website logins, hosting panel access or API keys, this release is relevant to you. On 1 November 2026 at 22:16:50 UTC (early 2 November in Vietnam), the project published release 1.37.5, which contains two security fixes. Everything below was checked as of 3 November 2026.
Who this concerns
Only operators of a self-hosted Vaultwarden instance. Using Bitwarden’s hosted service does not make you a Vaultwarden operator, so this release does not apply there. If a provider runs Vaultwarden on your behalf, ask them which version is deployed and when they plan to update.
What was fixed
The release notes list two advisories:
- GHSA-x9cq-f669-vrr4, affecting website icons, rated medium (5.3) by the project.
- GHSA-9pjj-f9g5-3x4c, affecting emergency access, rated medium (4.3).
Emergency access is the authorized recovery feature that lets a trusted contact request access to an account. Both advisories are still private while CVE assignment and publication are pending, so the exact affected versions, prerequisites, technical impact and exploitation status are not public. What the project does say is that it strongly advises updating as soon as possible. Because a credential server often sits behind other website operations, a medium rating still deserves a prompt, scheduled update rather than a “later” note.
Read the config changes before you pull the image
1.37.5 also makes some configuration fields stricter, and a rejected setting can stop the server from starting. Among the changes listed in the release notes: some rate-limit and database values must be at least 1, the minimum database connection count may not exceed the maximum, and the affected schedule settings must be empty or a valid cron expression. Compare your environment file or settings against the release notes first, so a security update does not turn into an outage.
One compatibility note from the release: if you use web vault 2026.7.1 or later, updating the server to 1.37.5 is required to switch two-step login methods, and if you use web vault 2026.9.0 or later, it is required to perform an authorized emergency access takeover (the recovery step where a trusted contact gains access). The bundled web vault is v2026.10.1.
A practical checklist
- Confirm whether Vaultwarden is actually in use, and record the image and version that is running right now, not the one you believe was deployed.
- Back up the database and the persistent data (configuration, keys, attachments) the way your deployment already does, and check that the backup can be restored. Our backup guide covers restore testing.
- Review your configuration against the validation changes above.
- Write down your rollback path and any client compatibility notes before changing anything.
- Replace the running container with the reviewed 1.37.5 image using your established update procedure. The project’s updating guide describes keeping mounted data intact while recreating the container.
- Validate startup, login, sync and two-factor login with your own accounts. If you rely on emergency access, test it only between accounts you are authorized to use. Never run a recovery test against someone else’s account.
- Keep watching logs and alerts afterwards. Monitoring beyond uptime explains what to watch.
Adapt these checks to your own deployment; not every test applies to every setup.
What remains uncertain
Because the advisories are private, upgrading applies the fixes the project has published but is not an all-clear, and a lack of reported exploitation does not mean none occurred. Keep an eye on both advisories until they are published. If you open a support ticket with anyone, share version numbers and log excerpts, never your configuration secrets or keys.