Vaultwarden 1.37.3 hardens pre-login rate limiting and revokes 2FA remember tokens
Vaultwarden 1.37.3, released on September 13, 2026, adds rate limiting to the pre-login and auth request endpoints and revokes 2FA remember tokens when credentials change. For a self-hoster, it is a security update to apply without delay.
July 24, 2026. Vaultwarden ships the 1.37 series of its Bitwarden-compatible password server. August 22, 2026. Version 1.37.2 lands with a batch of bug fixes. September 13, 2026. 1.37.3 ships with two fixes explicitly tagged “security”: rate limiting on the pre-login and auth request endpoints, and revocation of 2FA remember tokens when credentials or 2FA change. Why it matters: a self-hosted password manager is a prime target, and these two fixes close real attack angles on authentication.
What Vaultwarden is, in one sentence
Vaultwarden is the unofficial implementation of the Bitwarden server, written in Rust, built to be lightweight and easy to self-host. Where the official server demands a .NET stack and several containers, Vaultwarden runs in a single Docker container that handles vaults, authentication, and organizations. It is one of the most widely deployed pieces of the homelab, precisely because it centralizes the most critical secret there is: passwords.
That centralization has a corollary. Everything touching authentication — pre-login, sign-in, 2FA — becomes an attack surface of its own, and the 1.37.3 fixes target exactly that surface.
Rate limiting where it counts
The first fix adds rate limiting to the pre-login and auth request endpoints. Pre-login is the step where a client fetches the account’s KDF parameters before sending the password; authentication covers ordinary logins and login-with-device requests.
The stakes are twofold. Without limits, an attacker can hammer these endpoints to brute-force passwords or, more simply, saturate the server — a cheap DoS against an exposed service. Rate limiting does not stop a determined attacker who holds the master hash, but it makes mass attempts noisy, slow, and therefore detectable.
For a self-hoster, this is the kind of protection you ignore until you have been targeted. A Vaultwarden server published behind a reverse proxy is visible to the whole world; built-in rate limiting adds a line of defense that does not depend on your proxy configuration.
Revoking “remember this device” tokens
The second fix, just as important, concerns 2FA remember tokens. When a user checks “remember this device,” Vaultwarden issues a token that spares them from re-entering the 2FA code on every login. Before 1.37.3, those tokens could outlive a password change or a 2FA configuration change.
The consequence is concrete: if a credential is compromised and the victim then changes their password, a remember token issued before the change could, in some scenarios, still be accepted. The fix now revokes those tokens as soon as credentials or 2FA change — the response you would expect from a system that handles secrets.
The same release hardens logging: Vaultwarden now records the IP address and username on two-factor email-login credential failures. That is a valuable signal for spotting a credential-stuffing campaign aimed at a specific account, and it feeds directly into your detection rules.
The rest of the batch
1.37.3 is not only about security. It adds an SSO_SIGNUPS_ALLOWED variable to control whether newcomers can create an account through SSO, and admin reset of 2FA — useful when a user loses their second factor and self-service email reset is disabled. It also fixes password changes with recent web-vault versions, a broken migration on MariaDB 12.2.2, and organization imports that failed when certain field groups were missing. Five new contributors took part in the release.
Upgrading to 1.37.3
The official image is vaultwarden/server, and the upgrade follows the usual Docker path:
docker compose pull vaultwarden
docker compose up -d vaultwardenBack up the data volume and the database before upgrading. 1.37.3 introduces no major schema migration relative to 1.37.2, but a password manager is never updated without a backup first. Then check the logs for the new rate-limiting and 2FA-failure entries appearing.
Why self-host a password manager
The choice to self-host is not trivial. Handing your passwords to Bitwarden or another host means delegating security to a third party; self-hosting means taking it back — with everything that implies. Vaultwarden costs almost nothing to run: a Docker container, a SQLite or PostgreSQL database, and a few hundred megabytes of RAM. In exchange, the administrator becomes responsible for availability, backups, and above all, applying security patches.
That last point is what 1.37.3 illustrates. An unpatched password manager is a prime target: the credentials it protects are worth more than any other asset, and delayed patches are open windows. Rate limiting and 2FA token revocation are not features — they are baseline expectations for a service that centralizes secrets.
A few simple checks complete the upgrade: expose Vaultwarden only behind an HTTPS reverse proxy, enable 2FA at the organization level, restrict signups with SSO_SIGNUPS_ALLOWED, and watch the 2FA-failure logs that 1.37.3 begins emitting. An encrypted offsite backup of the volume remains the last line of defense.
A compatible engine, not a fork
One detail in the changelog — “Fix password change with newer web-vault” — reveals how Vaultwarden is built. It is not a fork of Bitwarden’s server but an independent reimplementation in Rust that speaks the same API, which means it must keep pace with the official web-vault client that Bitwarden ships. When the client changes how it submits a password change, the server has to follow, or a routine action silently breaks.
That coupling is the price of compatibility, and it explains why Vaultwarden releases mix two kinds of change: security and correctness fixes in its own code, and adjustments to track the moving target of the official client. For a self-hoster, the practical lesson is to update both together — the container and the web-vault it serves — and to treat a release like 1.37.3 that carries both a security fix and a client-compatibility fix as doubly worth applying.
A rate-limit note after the upgrade: the new limits can surprise legitimate clients that reconnect in a burst — a fleet of devices waking after a network outage, for instance. If you see unusual authentication failures, check the rate-limit logs before blaming the clients. The defaults are conservative; do not loosen them, and only raise them if your fleet genuinely needs it. Remember-token revocation also has a visible effect: users will have to re-enter their 2FA code after a password change, which is the intended behavior.
For most homelabs, the upgrade is a single pull and restart — the risk is not in the migration but in skipping it. A password manager is one of the few services where an unpatched instance can turn a single leaked credential into a fleet-wide compromise.
Verdict
1.37.3 is a targeted security update, not a major release — and that is exactly why it should be applied quickly.
If you self-host Vaultwarden exposed to the Internet, schedule the upgrade this week: rate limiting and 2FA token revocation close two real gaps, and the migration cost is near zero. If your instance sits behind a VPN or is strictly internal, the risk is lower, but the remember-token revocation alone justifies the upgrade. If you manage multiple users, enable SSO_SIGNUPS_ALLOWED and admin 2FA reset: they are two governance levers that will save you emergency support tickets.