Security · Vaultwarden

Vaultwarden's security release: a removed member could still read ciphers

Seven advisories in v1.37.4, topped by a High-severity organization revocation flaw; the upgrade notes change how proxy client IPs resolve and ask admins to rotate an API key.

By BoneThursday 8 October 20262 min readSecurity

entryread only

filedThursday 8 October 2026

length2 min

sectionSecurity

subjectVaultwarden

sourceson the page

Vaultwarden, the lightweight Rust server that most self-hosters run in place of Bitwarden’s own, shipped 1.37.4 on October 5 with seven security fixes and one plain instruction: update as soon as possible. The advisories are private for now, pending CVE assignment, but the list is public, and it reads like a bad day in an organization’s admin panel. The worst, rated High at 8.1, is organization member revocation: someone removed from an organization could keep reading its ciphers. The rest cover two-factor authentication and organization invitations at 6.8, attachments at 6.5, organization event logs and cipher sharing at 4.3, and the organization API key at 3.8. Two notes of context from the release: the advisories stay private until CVE assignment, which is why the list describes impact without exploit detail, and the release also carries dependency updates and minor security enhancements on top of the seven.

That last one comes with advice worth quoting: if an organization has admins you do not fully trust, consider rotating its API key after updating. The admin console has the rotation button under Settings. In a password manager, the entire product promise collapses if “removed” does not mean removed everywhere and immediately, so the revocation fix is the one to care about; the other six are the kind of audit findings that keep a project honest.

The upgrade notes are the trap

The part that will bite people is the proxy change, because almost nobody reads release notes for a patch release. With IP_HEADER=X-Forwarded-For, the client IP is now resolved to the rightmost address that is not listed in IP_HEADER_TRUSTED_PROXIES, where it used to be the leftmost. If your setup has a CDN in front of nginx, add every proxy in the chain to the trusted list, or rate limiting and logs will record the address of the proxy in front instead of the client behind it. The same notes also cover the smaller breakages: Sends can no longer be received by command-line clients older than 2026.4.2, a set of retired feature flags must be cleaned out of the environment or saving admin settings fails, the legacy register and prelogin endpoints are gone, and the Alpine image meeting a MySQL or MariaDB server without encrypted connections now needs an environment variable to start.

My read

Seven fixes, no drama, and the notes page most people skip carries both the step that breaks setups and the one that should be policy. Take the update, read the four upgrade notes, and if an organization you run has admins you do not fully trust, rotate that key today. Revocation bugs are the reminder why the boring advice, patch quickly, is load-bearing for a tool that holds everything. The project’s habit of shipping fixes fast, with honest notes and no theatrics, is the other half of why so many people trust it with their vaults.

Source: the v1.37.4 release.

SecurityVaultwarden 1.37.5 fixes two private advisories, and its config check now refuses to startVaultwarden 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.

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.