Yesterday, I tried to update Bitwarden from version 2026.7.0 to 2026.8.0. However, after logging into Vaultwarden, my password vaults were empty. There was nothing unusual to be seen in the Docker log files either. The Firefox extension exhibited the same behavior: no passwords were present, and syncing was not possible. I had already reported the issue to Bitwarden, but they were unable to reproduce the problem.Yesterday, I tried to update Bitwarden from version 2026.7.0 to 2026.8.0. However, after logging into Vaultwarden, my password vaults were empty. There was nothing unusual to be seen in the Docker log files either. The Firefox extension exhibited the same behavior: no passwords were present, and syncing was not possible. I had already reported the issue to Bitwarden, but they were unable to reproduce the problem. Yesterday I also made two videos that show how this behavior manifests itself.
Here what you see in the desktop app
confirmed, we’re having the same problem. Some additional symptoms (for us at least).
If you log out of the user account in Bitwarden we’ve experienced the following:
- When logging back in, SSO completes in Vaultwarden, but Bitwarden gets stuck and never completes login
- Closing and relaunching Bitwarden shows the user as signed in, but Bitwarden then says that the master password is invalid (it’s not)
- Logging in to Vaultwarden web client works absolutely fine, and all credentials are visible.
Can confirm this here too
I have the same issue with 2026.7.0, so it might be that the Firefox plugin updated and that is the issue?
Downloaded the desktop app on the AppStore, also does not work.
just saw the vw version had updated 36mins ago 1.37.2, updated docker image/server and updated extension to .8 and now showing nothing after logging into extension, blank.
**the notes do state compatibility with 2026.8 clients
update1
logged out of extension and now i cant MFA via yubikey bio OR TOTP both say invalid.
if i then try to reenter my password to try again, it says invalid master password (which its not)
I can still log into the web version (using both yubi & totp) seems just via the 2026.8 extension i cannot
update2
i ended up removing the extension, re-adding and setup and now all ok
update3
to save needing to remove the extension, be sure before updating 2026.7 to 2026.8 to log out of the extension (dont leave locked!), then udpate, then logs in fine, seems the only issues ive had is when it was locked, then tried the upgrade which could only be fixed with the reinstall.
Same symptom here, one version back (2026.7.0, not 2026.8.0) so this may not be your cause. But the check is cheap and rules it in or out in about two minutes.
The fingerprint: I could log in fine, vault list totally empty, but all my folders were still there. That combination is the tell. Folders come down a different shape in the sync response and decode normally; it’s the cipher list that dies. Empty items + intact folders almost certainly means client/server version mismatch, not data loss.
Root cause for 2026.7.0: Vaultwarden had been sending backwards-compat fields on vault items for years; leftovers from a restructure ~8 years ago that clients stopped needing around 2021. Bitwarden repurposed those same field names in 2026.7.0, so the new client reads the server’s leftovers as the new thing and the cipher decode blows up in the WASM layer. dani-garcia’s writeup: v1.37.0 (Upgrade to this version when using clients v2026.7.0+) · dani-garcia/vaultwarden · Discussion #7473 · GitHub — fixed in 1.37.0.
So: what Vaultwarden version are you actually on? One gotcha that cost "me’ time:/api/config reports the web vault version, not the server version. Mine said 2025.12.0 while the server was really 1.35.2. The startup banner is authoritative:
docker logs vaultwarden 2>&1 | grep -m1 -A1 "Starting Vaultwarden"
If that says anything below 1.37.0, update and you’re probably done.
Reading your logs before you panic. You said no unusual errors, and that’s expected — this failure is entirely client-side. What you should see, and what “I” saw, is auth and sync succeeding perfectly:
POST /identity/connect/token => 200 OK
GET /api/sync => 200 OK
I also grepped my whole log (31k lines) for bulk deletes and vault purges: none, ever. Zero SQLite errors, zero disk-full events. Server was fine the entire time; the client was throwing my items on the floor after receiving them.
Two things worth knowing before you touch anything:
- Do not log out of any client. Logging out purges the local encrypted cache, which may be the only copy you can still see. Locking is fine. Reinstalling the extension is fine. Logging out is not.
- Watch the WAL. My
db.sqlite3was 1 MB, butdb.sqlite3-walwas 2.5 MB — a month of writes that had never been checkpointed. If you back updb.sqlite3alone you get a snapshot from whenever the container last restarted, and it will look like data loss. Copy all three files together, or stop the container first so SQLite folds the WAL in. Mine went to 0 bytes the moment I stopped it.
Outcome: 1.35.2 → 1.37.2, about a minute of downtime, everything reappeared on the next sync. No restore, no re-import. Don’t import your emergency export on top or you’ll duplicate every entry.
On method, since it might be useful to someone: I didn’t do hardly any of this by hand. I had Claude driving my Synology DSM web UI in a browser tab (using the Claude extension). “He” was reading and searching the Container Manager logs, pulling file sizes and timestamps out of File Station, reconstructing the container’s update history, cross-referencing the GitHub issues, and then doing the pull → stop → reset → start. I typed my DSM password twice (it flatly refused to touch that) and made the go/no-go calls. It also caught the WAL problem before I copied anything, and built me a proper backup job that I ought to already have had in place. I was pretty traumatized when I logged in and saw nothing, but found a device that had everything still and exported to JSON. At that point I went for a run and turned over the post-mortem / forensics work to Claude, which is detailed above.