Home   2026-08-03 17:31:33

←

Software-update - Vaultwarden 1.37.0

Original article

Vaultwarden logo (79 pix)Vaultwarden is een onofficiële in Rust ontwikkelde implementatie van de Bitwarden wachtwoordmanager. Het gaat alleen om de serverkant van de wachtwoordmanager; voor de clients kan de officiële software van Bitwarden worden gebruikt. Vaultwarden is lichter in gebruik en heeft ook functionaliteit waarvoor bij Bitwarden moet worden betaald, waaronder het kunnen opslaan van bijlagen en beheer van wachtwoorden op organisatieniveau. Versie 1.37.0 van Vaultwarden is uitgekomen en hierin zijn de volgende veranderingen en verbeteringen aangebracht:

Note

This update is required for support with clients with version 2026.7.0+, please update before reporting any issues with them.

Security Fixes

This release contains security fixes for the following advisories. We strongly advice to update as soon as possible.

These are private for now, pending CVE assignment and publishing at a later date.

What's Changed
  • OpenDAL S3 parameter support in #6127
  • Fix SSO Cookie path in #7187
  • fix email 2fa for bw cli in #7225
  • sso_auth improvements in #7197
  • Reject unrecognised DATABASE_URL instead of silent SQLite fallback in #7061
  • Switch to xx-cargo in #6640
  • Updates and fixes in #7235
  • Switch to Edition 2024, more clippy lints, and less macro calls in #7200
  • Serve Apple app site association file in #7191
  • Update Rust, Crates and GHA in #7307
  • Fix enforce blocked in #7246
  • Admin password recovery endpoint change in #7270
  • fix(sends): emit hideEmail as non-null boolean in sync response in #7283
  • Org membership delete remove Invitation in #7284
  • [v2026.5.0] Registration request update in #7295
  • [v2026.5.0] PutPolicy now using vnext format in #7296
  • 2026.6.0 send support in #7346
  • Add SSO_AUTHORIZE_BODY in #7357
  • Add pm-26340-linux-biometrics-v2 feature flag in #7358
  • improve CI in #6991
  • Misc updates and fixes in #7406
  • Remove old compatibility code in #7434
  • Fix compilation with newer rust-musl version in #7453
  • Fix Custom Role CSS for new dialog markup in #7442
  • Remove unused fields in #7458
  • Update API response, crates and GHA in #7470
  • Trusted proxy support, unauthenticated rate limit & other fixes in #7472

Vaultwarden

Versienummer 1.37.0
Releasestatus Final
Besturingssystemen Linux
Website Vaultwarden
Download https://github.com/dani-garcia/vaultwarden/releases/tag/1.37.0
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

Feedback • 24-07-2026 19:50 45

24-07-2026 • 19:50

45

Bron: Vaultwarden

Reacties (45)

Financieel natuurlijk interessant, maar hoe blijft t project bestaan? Duurzaam dus?

Zijn er meerdere main developers? Is er een donatie optie?
Er zijn meerdere developers, waaronder mede Tweaker @BlackDex, die ook regelmatig de releases doet.

De "oprichter", Dani Garcia, is daarnaast ook al een flinke tijd (2 jaar of zo gok ik?) in dienst van Bitwarden. Maar in principe staat dat los van elkaar bij mijn weten. Hij werkt voor Bitwarden aan Bitwarden, maar daardoor heeft die ook een kijkje in de keuken waardoor die soms op zaken vooruit kan lopen. Toen alweer een tijd terug (vorig jaar ergens) Bitwarden werkte aan native mobile apps kon hij dus "meteen" zien dat er bepaalde zaken incompatibel waren met Vaultwarden. En nog voordat de publieke beta van de nieuwe apps verscheen waren deze problemen al opgelost in Vaultwarden.

En zo te zien hebben beiden het sponsor "gebeuren" van GitHub ingesteld: Dani Garcia, BlackDex (en daarnaast staan er hier en daar ook nog linkjes naar andere opties voor te sponsoren / doneren).

[Reactie gewijzigd door RobertMe op 25 juli 2026 09:03]

Ja, ja, ja en ja.

https://vaultwarden.com

[Reactie gewijzigd door xoniq op 24 juli 2026 21:14]

https://vaultwarden.com is een Vaultwarden instance die door iemand anders is opgezet. Donaties daaraan gaan naar de instance en niet naar het project. Zie: https://vaultwarden.com/#faq

[Reactie gewijzigd door MrKite op 24 juli 2026 21:55]

Ah my bad. Dat is dan wel ruk dat diegene het hoofddomein heeft gekaapt.
Vaultwarden heeft het domein https://vaultwarden.org/ alle andere hebben niks met het project Vaultwarden zelf te maken buiten het feit om dat ze een server versie van ons gebruiken.

Ik wil er wel op wijzen dat je niet kan weten of dat deze veilig zijn en of dat de code van de web-vault en server is aangepast om kwaadaardige bedoelingen mee te hebben.
Ik vertrouw sowieso geen enkele derde partij met mijn wachtwoorden. Al helemaal geen hobbyisten die een vaultwarden instance draaien.

Zelfde met Immich, die foto management pakket, draai ik ook zelf maar zal nooit bij iemand aankloppen die dat publiekelijk host.
Ik heb dus geprobeerd dit op zetten via een vm, maar heb aardige ruzie met de admin-token... Jammer dat de wiki daar onvoldoende bij helpt.

[Reactie gewijzigd door marc574 op 24 juli 2026 22:23]

Nee, helaas werkt de token dan niet. Ik krijg geen foutmelding maar m'n wachtwoord werkt niet.
Hoe heb je de token gegenereerd?
Uiteindelijk gelukt door eerst een makkelijk wachtwoord aan te maken en daarna dat te veranderen via de gui van vaultwarden. Ik denk dat er een teken in mijn wachtwoord zat waar die moeite mee had.
Een $ moet je escapen in een docker compose met een ander $.

environment:
PASSWORD: "abc$vdQs123"

Compose leest $vdQs als variabele.

Dus de fix:

environment:
PASSWORD: "abc$$vdQs123"

[Reactie gewijzigd door nullbyte op 25 juli 2026 19:31]

precies als in de handleiding: echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 65540 -t 3 -p 4

daarna ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$xxxxxxxxxxxxxxxxxxxxxxxxxx
Je zou eens met Gemini kunnen proberen erbij te laten helpen. Die heeft voor mij ook de docker-compose.yml opgeschoond waar ik nog oude meuk in had wat allang niet meer relevant is.
Heb het geprobeerd met Claude, maar ergens blijft er toch iets misgaan. Of de admin token klopt niet en is niet herkent als hash, of m'n wachtwoord werkt niet.

Ik ga het van de week nog eens proberen met Gemini.
Dit kreeg ik van Gemini bijvoorbeeld toen ik de YAML postte (uiteraard zonder hash erin, die vervangen door <platte hash> dan snapt Gemini dat ik die gecensureerd heb):
Het korte antwoord: het werkt grotendeels, maar er zitten een paar opvallende schoonheidsfoutjes, overbodige instellingen en een veiligheidsrisico in.

Hier zijn de belangrijkste punten om aan te passen voor een stabiele en veilige setup:

1. Belangrijkste verbeterpunten

ADMIN_TOKEN (Veiligheidsrisico): Het invullen van een gewone platte tekst string in ADMIN_TOKEN is in nieuwere Vaultwarden-versies verouderd. Gebruik bij voorkeur een Argon2 hash (te genereren via vaultwarden hash of de Admin GUI generator) om te voorkomen dat je wachtwoord uitlekt via environment variabelen of logs.

Overbodige variabelen:

command: - /start.sh: De officiële Docker-image heeft dit al ingebouwd. Handmatig overschrijven kan updates in de toekomst breken.

PATH: Hoef je niet op te geven, dit zit al in de container gedefinieerd.

ROCKET_ENV=staging: Zet dit liever niet op staging (dit kan onnodige debug-logs veroorzaken). Rocket draait standaard prima op productie.

ROCKET_PORT=80 en ROCKET_ADDRESS=0.0.0.0: Dit zijn al de standaardwaarden binnen de container.

Geen HTTPS (Let op!): Bitwarden-clients (apps en browserextensies) weigeren te werken zonder HTTPS/TLS (behalve op localhost). Zorg dat je hier een reverse proxy voor zet (zoals Nginx Proxy Manager, Caddy, of Traefik) met een SSL-certificaat.

Verborgen spaties: In je originele snippet zitten non-breaking spaces (\u00a0). Als je die direct in een .yml bestand plakt, geeft Docker Compose een YAML-parsing-fout.
Voor zulke dingen is een chatbot wel nuttig om oude configs op te schonen als je een beetje de vinger op de pols houdt en bereid bent om in te zien of ie fouten maakt of juist niet.

De uiteindelijke opgeschoonde YAML vanuit Gemin:
services:

vaultwarden:

image: vaultwarden/server:latest

container_name: vaultwarden

restart: always

environment:

- TZ=Europe/Amsterdam

- WEBSOCKET_ENABLED=true

# Tip: Gebruik bij voorkeur een Argon2 PHC hash in plaats van platte tekst

- ADMIN_TOKEN=<token>

labels:

- flame.type=app

- flame.name=Vaultwarden

- flame.url=http://<lokale IP>:8003

ports:

- 8003:80/tcp

volumes:

- ./vw-data:/data

mem_limit: 256M

mem_reservation: 128M

vaultwarden-backup:

image: bruceforce/vaultwarden-backup:latest

container_name: vaultwarden-backup

restart: on-failure

init: true

depends_on:

- vaultwarden

volumes:

- ./vw-data:/data/

- /nas_vwbackup:/backup/

env_file:

- .env

mem_limit: 256M

mem_reservation: 128M

[Reactie gewijzigd door xoniq op 24 juli 2026 22:30]

Container vaultwarden: depends_on: - vaultwarden?
Nee, dat is een andere container: "vaultwarden-backup".
Het is gelukt, mijn wachtwoord was denk ik te moeilijk.. Eerst een eenvoudig wachtwoord aangemaakt, daarna via de gui van vaultwarden de token aangepast.
...

[Reactie gewijzigd door BlackDex op 25 juli 2026 11:08]

Is deze wiki niet voldoende?

https://github.com/dani-g...ge#secure-the-admin_token

Er staat uitgelegd hoe je deze moet genereren en waar je op moet letten met compose etc..
Vraagje voor de mensen die er verstand van hebben: hoe veilig is het om een vaultwarden endpoint publiek te maken vanuit homelab?
Niks mis mee wat mij betreft.

Zorg er voor dat je een sterk wachtwoord hebt, 2FA aan staan.

Ookal krijgt iemand het voor elkaar jou database te bemachtigen, al dan niet via een API call, of direct van je server, alle items zijn encrypted, en kunnen alleen met je wachtwoord worden decrypt.

Gebruik Argon2id als KDF wat er voor zorgt dat brute-force attempts minder effectief is.
Cool, had nog niet van Argon2id of de term KDF gehoord - bedankt voor de tips!

Verder nog nuttig om bepaalde software toe te voegen aan de reverse proxy? Ik hoorde iets van een tool dat automatisch te veel login attemps IP blocken, e.d.

Ook zat ik er aan te denken om GEO-whitelisting toe te passen, en alleen vanuit bijvoorbeeld Nederland verbinding toe te laten - en dat handmatig aan te passen mocht ik naar het buiten land gaan.
Onveilig per definitie. Wat ik doe, mijn instance blijft volledig offline, maar ik gebruik Tailscale voor een prive verbinding mijn eigen netwerk in waardoor het daar gewoon verbind met de lokale IP.
Niks is veilig om direct publiekelijk beschikbaar te maken vanaf een thuisnetwerk
Best practice op cyber security gebied is b.v. een openvpn server hosten (op je router, nas, thuisservertje) en alllen deze vpn verbinding aanbieden op een niet well known poortnummer. Daarna kan je via een wachtwoord + private key verbinding maken met het huisnetwerk via een vpn verbinding. De private key heb je dan dus al in de ovpn client staan op het device waarmee je verbinding gaat maken.

Verder niets openzetten naar het internet, onnodig en onveilig.

Ja als iemand via een api call je DB opvraagd is die versleuteld. Maar waarom zou je, gewoon dichtzetten en een vpn gebruiken.

[Reactie gewijzigd door nullbyte op 25 juli 2026 17:32]

Bedankt voor de feedback :)
Maar waarom zou je, gewoon dichtzetten en een vpn gebruiken.
Omdat ik voor meerdere gebruikers, zoals familie / vrienden de service ook wil aanbieden. En het laatste dat ik wil is dat mijn ouders hoeven te klooien met een VPN.

Als ik alleen Vaultwarden openstel, via bijvoorbeeld Caddy, met goede instellingen - en Vaultwarden zelf goed instel (dus admin panel disablen, etc etc) - is het dan nog wel zo'n groot risico?
Zojuist via docker geupdate naar image vaultwarden/server:1.37.0 . Werkt prima.
edit:
Versienummer niet goed overgenomen, excuses!

[Reactie gewijzigd door aCiDcHaOZ op 26 juli 2026 12:01]

Met image vaultwarden/server:latest blijft mijn instance 2026.6.4:
docker pull vaultwarden/server:latest

latest: Pulling from vaultwarden/server

Digest: sha256:e6443e3d5ed8fcee2204b89ec778d7f24d0173bcc42d1ea34f990304f5f63f51

Status: Image is up to date for vaultwarden/server:latest

docker.io/vaultwarden/server:latest
Met 1.37 ipv latest:
docker pull vaultwarden/server:1.37

Error response from daemon: manifest for vaultwarden/server:1.37 not found: manifest unknown: manifest unknown

[Reactie gewijzigd door xoniq op 24 juli 2026 22:09]

Ze wijzen beide naar dezelfde Digest hash, dus dat zit echt aan jouw kant: https://hub.docker.com/r/vaultwarden/server/tags
Ah ik zie dat @aCiDcHaOZ een '.0 miste:
docker pull vaultwarden/server:1.37.0
Maar wel raar dat ik met een docker pull vaultwarden/server:latest nog gewoon die andere hash krijg. Geen idee hoe dat dan zit.

Zal wel browser cache zijn, op de login pagina blijft 2026.6.4 staan terwijl ik 'm wel nu gepulled heb op die manier als in mijn 'citaat' en die gekoppeld in de docker compose.

[Reactie gewijzigd door xoniq op 24 juli 2026 22:55]

De hash die je bij "latest" terug kreeg is ook de 1.37.0 versie. Heb je de container wel opnieuw aangemaakt? Alleen de image pullen zorgt er niet voor dat je bestaande containers ook bijgewerkt worden.

In het geval van Docker Compose:
docker compose pull
docker compose up -d
Los daarvan zou ik voor dit soort servers trouwens afraden om "latest" te gebruiken. Voor dit soort kritieke diensten wil je liever precies weten welke versie je gebruikt.

[Reactie gewijzigd door Saeverix op 24 juli 2026 23:09]

Los daarvan zou ik voor dit soort servers trouwens afraden om "latest" te gebruiken. Voor dit soort kritieke diensten wil je liever precies weten welke versie je gebruikt.
Waarom dan? Latest heeft ook bugfixes en veiligheidsupdates. En is in principe stabiel. Gewoon goede backups hebben lijkt me cruciaal. Maar up-to-date houden ook.

Mijn vaultwarden draait op een vm met andere cruciale diensten in proxmox en voor de cruciale diensten maak ik dagelijks een (incremental) backup. Die ook weer dagelijks wordt gebackupt naar een andere plek. Minder cruciale dingen doe ik wekelijks.
Er komt een moment dat versie 2.x uitkomt. Bij major updates heb je kans op "breaking changes", en dat wil je dan wel op een bewust moment doen met goede voorbereiding en backups. Anders heb je ineens een kapotte Vaultwarden op een moment dat niet goed past.
Klinkt vrij spannend voor het maken van een snapshot. Zelf stop ik de container sons ook even en maak een backup van de bindmounts naar een andere node voor het geval de snapshot te verouderd raakt. Maar je hebt gelijk, zorg altijd voor een weg terug. Regel 1 in IT beheer.

ik copy en comment de image regel in de compose altijd uit. Zo weet ik welke versies ik gebruikt heb.
Ja had die image gepulled, de image met de juiste versie vastgezet in de docker compose file, en up -d. Dus hij heeft wel de juiste versie. Ook werken bij mij de Bitwarden plugins gewoon die op de beruchte versie zitten.

Dus het zal wel goed wezen.
docker ps -a
docker image ls -a
Als ik Vaultwarden in Docker op mijn NAS wil draaien, maar ik wil mijn NAS absoluut niet openzetten naar buiten toe, zodat de clients alleen op mijn thuisnetwerk kunnen syncen met de server, werkt dan toch nog alle functionaliteit op de clients buitenshuis en worden wijzigingen dan bij thuiskomst alsnog gesynced?
Dank je wel. Da's fijn om te horen. Ik zal er eens mee gaan experimenteren. :-)
Houdt er dan ook rekening mee dat je buitenhuis geen nieuwe acounts kan aanmaken of bestaande kan aanpassen. Verder werkt het prima.
Voor wie nog niet onmiddellijk wil of kan z'n eigen Vaultwarden server upgraden naar deze versie, maar wel verveeld zit met een niet-werkende Bitwarden extensie in Firefox: je kan je bitwarden extensie in Firefox downgraden met deze instructies: https://www.reddit.com/r/Bitwarden/comments/1v4ygv0/firefox_extension_202670_broken_against/
Klopt, ik had last van foutmeldingen/niet werkende extensie en kon met de laatste 2025 extensie de boel werkend krijgen. Als deze update gebruik van de laatste extensie (en app, ook daar problemen nu) mogelijk maakt ben ik erg blij!

Om te kunnen reageren moet je ingelogd zijn