Vaultwarden 1.36.0: Critical Security Fixes You Need to Apply Now
If you're running Vaultwarden on your seedbox or home server — and a lot of people in this community do, because it's the obvious choice for managing the dozens of tracker credentials, API keys, and service logins that come with running a serious media stack — stop what you're doing and update to 1.36.0.
This isn't a routine maintenance release. It patches real vulnerabilities with published CVEs. Here's what you need to know and exactly how to update.
What's Fixed in 1.36.0
Three security advisories are addressed in this release:
| Advisory | Type | Severity |
|---|---|---|
| GHSA-pfp2-jhgq-6hg5 | SSO Login CSRF | High |
| GHSA-w6h6-8r66-hcv7 | SSO Login CSRF (variant) | High |
| GHSA-hxqh-ff5p-wfr3 | User/Organization Enumeration | Medium |
SSO Login CSRF (the serious one)
If you've configured Vaultwarden with SSO — using something like Authelia, Authentik, or a third-party OIDC provider — this vulnerability could allow an attacker to hijack a login flow via a Cross-Site Request Forgery attack. In practical terms: a crafted link could potentially authenticate a victim into an attacker-controlled session.
If you're not using SSO and rely on standard email/password login, your exposure to this specific vector is lower — but you should still update. The enumeration vulnerability affects all configurations.
User/Organization Enumeration
This flaw allows an unauthenticated attacker to determine whether a specific user or organization exists in your Vaultwarden instance. On a private seedbox install with no public exposure this is low-risk, but if your Vaultwarden is internet-facing (which most are, since that's the whole point), it's a meaningful information leak that can assist targeted attacks.
How to Update
Docker Compose (most common setup)
Most seedbox self-hosters run Vaultwarden via Docker. Here's the standard update flow:
# Pull the latest image
docker pull vaultwarden/server:latest
# Bring down your current instance
docker compose down
# Bring it back up with the new image
docker compose up -d
# Verify the version
docker logs vaultwarden 2>&1 | grep "Vaultwarden version"
If you're pinning to a specific tag rather than latest (which is good practice), update your docker-compose.yml:
services:
vaultwarden:
image: vaultwarden/server:1.36.0
container_name: vaultwarden
restart: unless-stopped
volumes:
- ./vw-data:/data
environment:
DOMAIN: "https://vault.yourdomain.com"
SIGNUPS_ALLOWED: "false"
ports:
- "127.0.0.1:8080:80"
Then run:
docker compose pull && docker compose up -d
Unraid Users
If you installed via the Community Applications plugin, go to Docker → Vaultwarden → Edit, click Apply, and Unraid will pull the latest image. Alternatively, use the terminal:
docker pull vaultwarden/server:latest
docker stop vaultwarden
docker start vaultwarden
Verify Your Update
After restarting, confirm you're on 1.36.0 by checking the admin panel at https://your-vault-domain/admin or by inspecting the container logs:
docker logs vaultwarden 2>&1 | head -20
You should see something like:
INFO vaultwarden::util > Vaultwarden version 1.36.0
Before You Update: Back Up Your Data
Vaultwarden stores everything in a SQLite database (by default at /data/db.sqlite3). Before any update, snapshot it:
# If using the default Docker volume path
cp /path/to/vw-data/db.sqlite3 /path/to/vw-data/db.sqlite3.bak-$(date +%Y%m%d)
Or if you want a proper export, use Vaultwarden's built-in admin backup:
- Navigate to
https://your-vault/admin - Go to Backup section
- Download the backup file
This takes 30 seconds and means you're not gambling your entire credentials store on a smooth update.
Hardening Recommendations While You're In There
Since you're touching your Vaultwarden config anyway, here are a few settings worth reviewing:
Disable signups if you haven't already — there's no reason for a personal instance to accept new registrations:
SIGNUPS_ALLOWED: "false"
Restrict admin panel access by setting a strong token and ideally putting it behind your reverse proxy with IP allowlisting:
ADMIN_TOKEN: "your-very-long-random-string-here"
Enable 2FA on your Vaultwarden account if you haven't. TOTP works fine and takes two minutes to set up via the web vault.
Review your SSO config if you use it. The CSRF fix in 1.36.0 requires no config changes on your end, but it's worth re-reading your OIDC setup to make sure your OIDC_CLIENT_SECRET is still rotated and not exposed in logs.
Why This Matters for Seedbox Users Specifically
Your Vaultwarden instance probably holds credentials for:
- Private tracker accounts (RED, OPS, BTN, etc.)
- Seedbox provider login
- Sonarr/Radarr/Prowlarr API keys
- rclone remote configs
- VPN credentials
A compromised password manager is a complete wipe of your digital security posture. Private tracker accounts in particular are non-trivial to recover if lost or compromised — many trackers have strict policies around account sharing or suspicious login activity.
The update is a five-minute job. There's no reason to delay it.
Bottom Line
Update to Vaultwarden 1.36.0 today. The SSO CSRF vulnerability is serious if you're using SSO, and the enumeration flaw affects all internet-exposed instances. Back up your db.sqlite3 first, pull the new image, restart the container, and you're done. While you're at it, disable public signups and make sure your admin panel isn't exposed to the open internet.
The full release notes and security advisories are on the Vaultwarden GitHub releases page.