Vaultwarden 1.37.3 durcit le pré-login et révoque les jetons de mémorisation 2FA
La version 1.37.3 de Vaultwarden, publiée le 13 septembre 2026, ajoute une limitation de débit sur les points de terminaison de pré-login et d’authentification, et révoque les jetons de mémorisation 2FA quand les identifiants changent. Pour un self-hébergeur, c’est une mise à jour de sécurité à appliquer sans attendre.
24 juillet 2026. Vaultwarden publie la série 1.37 de son serveur de mots de passe compatible Bitwarden. 22 août 2026. La version 1.37.2 corrige une salve de bogues. 13 septembre 2026. La 1.37.3 sort avec deux correctifs explicitement marqués « sécurité » : une limitation de débit sur le pré-login et les points d’authentification, et la révocation des jetons de mémorisation 2FA quand les identifiants ou la 2FA changent. Pourquoi c’est important : un gestionnaire de mots de passe auto-hébergé est une cible de choix, et ces deux correctifs ferment des angles d’attaque réels sur l’authentification.
Ce qu’est Vaultwarden, en une phrase
Vaultwarden est l’implémentation non officielle du serveur Bitwarden, écrite en Rust, conçue pour être légère et simple à auto-héberger. Là où le serveur officiel exige une pile .NET et plusieurs conteneurs, Vaultwarden tient dans un unique conteneur Docker qui gère les coffres, l’authentification et l’organisation. C’est l’une des briques les plus déployées du homelab, précisément parce qu’elle centralise le secret le plus critique qui soit : les mots de passe.
Cette centralisation a un corollaire. Tout ce qui touche à l’authentification — le pré-login, la connexion, la 2FA — devient une surface d’attaque à part entière, et les correctifs de la 1.37.3 portent exactement sur cette surface.
Limiter le débit là où ça compte
Le premier correctif ajoute une limitation de débit sur les points de terminaison de pré-login et d’authentification. Le pré-login est l’étape où le client récupère les paramètres KDF du compte avant d’envoyer le mot de passe ; l’authentification couvre les connexions classiques et les demandes de connexion par appareil.
L’enjeu est double. Sans limitation, un attaquant peut marteler ces points de terminaison pour tenter des mots de passe en force brute ou, plus simplement, saturer le serveur — un DoS à faible coût contre un service exposé. La limitation de débit ne stoppe pas un attaquant déterminé qui dispose du hachage maître, mais elle rend les tentatives massives bruyantes, lentes et donc détectables.
Pour un self-hébergeur, c’est le genre de protection qu’on néglige tant qu’on n’a pas été ciblé. Un serveur Vaultwarden publié derrière un reverse proxy est visible du monde entier ; la limitation de débit intégrée au serveur ajoute une ligne de défense qui ne dépend pas de la configuration du proxy.
Révoquer les jetons « rester connecté »
Le second correctif, tout aussi important, touche aux jetons de mémorisation 2FA. Quand un utilisateur coche « se souvenir de cet appareil », Vaultwarden émet un jeton qui lui évite de ressaisir le code 2FA à chaque connexion. Avant la 1.37.3, ces jetons pouvaient survivre à un changement de mot de passe ou de configuration 2FA.
La conséquence est concrète : si un identifiant est compromis puis que la victime change son mot de passe, un jeton de mémorisation émis avant le changement pouvait, dans certains scénarios, continuer d’être accepté. Le correctif révoque désormais ces jetons dès que les identifiants ou la 2FA changent — la réaction attendue d’un système qui traite des secrets.
Le même lot durcit la journalisation : Vaultwarden enregistre maintenant l’adresse IP et le nom d’utilisateur lors des échecs de connexion par e-mail 2FA. C’est un signal précieux pour repérer une campagne de credential stuffing ciblant un compte précis, et il alimente directement vos règles de détection.
Les autres changements du lot
La 1.37.3 ne se limite pas à la sécurité. Elle ajoute une variable SSO_SIGNUPS_ALLOWED qui permet de contrôler si les nouveaux venus peuvent se créer un compte via SSO, et un support de réinitialisation de la 2FA par l’administrateur — utile quand un utilisateur perd son deuxième facteur et que l’auto-réinitialisation par e-mail est désactivée. Elle corrige aussi le changement de mot de passe avec les versions récentes du web-vault, une migration cassée sur MariaDB 12.2.2, et l’import d’organisation qui échouait en l’absence de certains groupes de champs. Cinq nouveaux contributeurs ont participé au lot.
Passer à la 1.37.3
L’image officielle est vaultwarden/server, et la mise à niveau suit le chemin habituel d’un déploiement Docker :
docker compose pull vaultwarden
docker compose up -d vaultwardenAvant de mettre à niveau, faites une sauvegarde du volume de données et de la base. La 1.37.3 n’introduit pas de migration de schéma majeure par rapport à la 1.37.2, mais un gestionnaire de mots de passe ne se met jamais à jour sans sauvegarde préalable. Vérifiez ensuite, dans les journaux, l’apparition des nouvelles entrées de limitation de débit et de journalisation des échecs 2FA.
Un point d’attention après la mise à niveau : la limitation de débit peut surprendre des clients légitimes qui se reconnectent en rafale — une flotte de terminaux qui se réveille après une coupure réseau, par exemple. Si vous constatez des échecs d’authentification inhabituels, consultez d’abord les journaux de limitation de débit avant d’incriminer les clients. Les seuils par défaut sont conservateurs ; ne les abaissez jamais, et ne les relevez que si votre parc le justifie. La révocation des jetons de mémorisation a, elle aussi, un effet visible : vos utilisateurs devront ressaisir leur code 2FA après un changement de mot de passe, ce qui est le comportement attendu.
Pourquoi auto-héberger un gestionnaire de mots de passe
Le choix de l’auto-hébergement n’est pas anodin. Confier ses mots de passe à Bitwarden ou à un autre hébergeur, c’est déléguer la sécurité à un tiers ; les auto-héberger, c’est la reprendre — avec tout ce que cela implique. Vaultwarden ne coûte presque rien à faire tourner : un conteneur Docker, une base SQLite ou PostgreSQL, et quelques centaines de mégaoctets de RAM. En échange, l’administrateur devient responsable de la disponibilité, des sauvegardes et, surtout, de l’application des correctifs de sécurité.
C’est ce dernier point que la 1.37.3 illustre. Un gestionnaire de mots de passe non patché est une cible de choix : les identifiants qu’il protège valent plus que n’importe quel autre actif, et les correctifs qui tardent sont autant de fenêtres ouvertes. La limitation de débit et la révocation des jetons 2FA ne sont pas des fonctionnalités, ce sont des attentes de base pour un service qui centralise des secrets.
Quelques vérifications simples complètent la mise à niveau : exposer Vaultwarden uniquement derrière un reverse proxy en HTTPS, activer la 2FA au niveau de l’organisation, limiter les inscriptions avec SSO_SIGNUPS_ALLOWED, et surveiller les journaux d’échecs 2FA que la 1.37.3 commence à émettre. Une sauvegarde chiffrée du volume hors site reste la dernière ligne de défense.
Verdict
La 1.37.3 est une mise à jour de sécurité ciblée, pas une version majeure — et c’est précisément pour cela qu’il faut l’appliquer vite.
Si vous auto-hébergez Vaultwarden exposé à Internet, planifiez la mise à niveau cette semaine : la limitation de débit et la révocation des jetons 2FA ferment deux angles réels, et le coût de migration est quasi nul. Si votre instance est derrière un VPN ou strictement interne, le risque est moindre, mais la révocation des jetons de mémorisation vaut à elle seule la mise à niveau. Si vous gérez plusieurs utilisateurs, activez SSO_SIGNUPS_ALLOWED et la réinitialisation admin de la 2FA : ce sont deux leviers de gouvernance qui vous éviteront des tickets de support en urgence.