Security · Vaultwarden

Vaultwarden 1.37.5 fixes two private advisories, and its config check now refuses to start

Vaultwarden 1.37.5 carries fixes for two Medium advisories, website icons at 5.3 and emergency access at 4.3, both still private pending CVE assignment and publication. The upgrade note that matters most is configuration: invalid values now stop startup with an error rather than being tolerated, the bundled web vault moves to v2026.10.1, and self-served vaults older than v2026.7.1 may have compatibility problems.

By BoneMonday 2 November 20263 min readSecurity

entryread only

filedMonday 2 November 2026

length3 min

sectionSecurity

subjectVaultwarden

sourceson the page

Vaultwarden 1.37.5, published on 1 November, is a security release. The notes open with “This release contains security fixes for the following advisories. We strongly advise updating as soon as possible”, and then list two.

What the release says about the advisories

There are exactly two, both Medium: “Website icons” at 5.3 with the identifier GHSA-x9cq-f669-vrr4, and “Emergency access” at 4.3 with GHSA-9pjj-f9g5-3x4c. That is the whole of the disclosure, and the release says why: “These are private for now, pending CVE assignment and publishing at a later date.”

There is nothing here about how either flaw works, which versions carry it, or whether anyone has used it. The advisory pages are private, and this piece will not guess at reachability. The action is certain: the fixed version exists, and shipping it is the mitigation.

This is the same shape as our 8 October piece on 1.37.4, which covered seven advisories under the same private-until-CVE rule, four weeks on. That piece also sets out what Vaultwarden is, if this is your first encounter with the project.

The upgrade note that will stop a container

The configuration section is the part likely to bite during the upgrade. In this release, “invalid values now stop startup with an error”, and numeric options have tighter types, so negative or oversized values are rejected instead of tolerated.

The release’s examples: values above 65535 for LOGIN_RATELIMIT_MAX_BURST, TRASH_AUTO_DELETE_DAYS, EVENTS_DAYS_RETAIN or SMTP_TIMEOUT, or above 255 for EMAIL_ATTEMPTS_LIMIT. The same sentence continues with rules for other settings: the rate-limit *_SECONDS and *_MAX_BURST options, DATABASE_TIMEOUT and DATABASE_IDLE_TIMEOUT must be at least 1, DATABASE_MIN_CONNS cannot be larger than DATABASE_MAX_CONNS, and DUO_CONTEXT_PURGE_SCHEDULE and PURGE_INCOMPLETE_SSO_AUTH must be empty or a valid cron expression.

Read that as an upgrade-order problem: a .env carried forward from an older release can hold a value nothing ever validated, and after this release the process does not start until it is fixed. Restarting a test instance first costs minutes and tells you which number is wrong, because the failure is now an error at boot rather than a setting quietly ignored.

Web vault compatibility

“The bundled web vault is now v2026.10.1. If you serve your own web vault older than v2026.7.1, you might have compatibility issues.” If you serve your own copy rather than the bundled one, that is the version line to check before upgrading.

The release also says the update is required before certain web-vault features work: 2026.7.1 and later needs it “to turn two-step login methods on or off”, and 2026.9.0 and later needs it “to take over an account through emergency access”. The notes ask you to update before reporting issues with either, which suggests those two misbehave against an older server.

Also in the release

Support for the new emergency access and account recovery password payloads the 2026.9.0 web vault sends, and a 2FA userVerificationToken for Authenticator, Email and Duo. Email 2FA for SSO logins on iOS and Android is fixed, WebSocket connections that stop responding are now closed, and the Duo and SSO purge schedules are validated at startup, which is the same strictness as the configuration changes above.

On the client side: Windows desktop Autotype feature flags and policy support, a biometrics-sdk-ipc feature flag, and revision_date on organisation policies. Group import now updates groups when data changes, auth requests are deleted with the user they belong to, and an unsupported riscv64 build exists.

Who should move now

Anyone running Vaultwarden for other people. The two advisories are fixed, unreadable until they are published, and the version that carries the fixes is out.

For a single-user instance the trade is smaller but the same shape: upgrade, then check that it came back. The configuration validation is the change that can turn a routine restart into an outage, so test it before the day you need the service. No upgrade command is reconstructed here, because the release record gives none, and nothing above was tested first-hand.

SecurityPyPI's new Security tab says where a release came from, and that is not a verdictPyPI's redesigned project pages went live on 6 November with a Security tab that reports a release's provenance: full, none, incomplete, inconsistent, changed or lost. The post is explicit that no provenance does not mean malicious, that it means the file origin cannot be cryptographically verified, and that the states worth checking before you install are the warnings.

SecurityPwnEscape Part 2: from a Firecracker guest to root on the host, in a setup without the jailerThe researchers behind October's kernel bug have published the other half: using that host-memory primitive to find Firecracker in memory, take over a live vCPU thread and redirect its return from KVM to a call of their choosing, with the VM left running and reachable. Their test used Firecracker v1.16.1 with the VMM launched as root and no jailer, and they say a jailer-hardened deployment needs a separate assessment. No new CVE, no vendor advisory and no Firecracker fix appears in the source.