Bitwarden Browser Extension 2026.7.0 shows empty vault while Web Vault and Extension 2026.6.1 working

[Zayeen]

Environment

• Vaultwarden: 1.36.0
• Web Vault: 2026.4.1
• Database: SQLite 3.51.3
• Browser: Firefox (also reproduced on fresh Chromium installation)
• Bitwarden Browser Extension:
  • 2026.6.1 ✅ Works
  • 2026.7.0 ❌ Empty vault

Problem

After upgrading the Bitwarden browser extension to 2026.7.0, login succeeds but the vault is completely empty.

Downgrading to 2026.6.1 immediately fixes the issue without changing anything on the server.

The Web Vault works correctly and displays all vault items.

Expected behavior

After login, the browser extension should synchronize and display all vault items.

Actual behavior

• Login succeeds.
• WebSocket connects successfully.
• The vault remains completely empty.
• The browser extension crashes internally.

Server log

The server behaves normally:

• Login succeeds (HTTP 200)
• /api/sync returns successfully for the Web Vault.
• No database errors.
• No crypto errors.
• No permission errors.

Browser console

The browser console reports:

Uncaught Error:
invalid type: JsValue(Object(...)), expected a string

The exception originates from the WASM client while processing a cipher.

The crypto initialization completes successfully before the crash:

INFO initialize_user_crypto
User crypto initialized successfully

After that, the extension throws:

invalid type: JsValue(Object(...)), expected a string

Additional information

• Vault originally imported from LastPass several years ago.
• Exported the complete vault to unencrypted JSON.
• Verified that all exported login fields have the expected data types.
• No malformed JSON or incorrect field types were found.
• Web Vault continues to function correctly.
• Firefox Extension 2026.6.1 works perfectly.
• Firefox Extension 2026.7.0 always reproduces the issue.
• Fresh Chromium installation with 2026.7.0 reproduces the same issue.

This appears to be a regression introduced in the 2026.7.0 browser extension.

[Zayeen]

Additional browser console output:

INFO initialize_user_crypto: User crypto initialized successfully

Uncaught Error:
invalid type: JsValue(Object(...)), expected a string

at Ae (bitwarden_wasm_internal_bg.js:6830:11)
at ...module.wasm

The exception occurs immediately after successful login while the extension processes vault items.

Additional observations:

• Web Vault works correctly.
• Firefox Extension 2026.6.1 works correctly.
• Firefox Extension 2026.7.0 always shows an empty vault.
• Fresh Chromium installation with 2026.7.0 shows exactly the same behaviour.
• The vault contains approximately 300 items.
• The vault was originally imported from LastPass years ago.
• Exported the vault to unencrypted JSON and verified there are no unexpected field types.

[Zayeen]

Downgrading from 2026.7.0 to 2026.6.1 fixes the issue immediately without any server-side changes.

[Zayeen]

The issue is reproducible in both Firefox and Chromium with extension 2026.7.0, while 2026.6.1 works in Firefox against the same Vaultwarden server and account.

[BlackDex]

It's probably also fixed if you use the :testing tagged container with the newer client versions.

[arthurbaer]

Can confirm this exact issue, reproduced independently with a different setup — adding details in case they help narrow it down:

Environment

• Vaultwarden: 1.36.0
• Database: Postgres (not SQLite)
• Browser: Microsoft Edge 150.0.4078.83
• Bitwarden Browser Extension: 2026.6.1 ✅ works / 2026.7.0 ❌ fails
• Desktop App 2026.7.0 also affected — same crash occurs there when loading the vault after login, not just in the browser extension
• Login method: master password + FIDO2 security key as second factor (not passwordless/PRF vault unlock)

Troubleshooting done

• Ruled out reverse proxy / CSP / security headers (server responses are 200 OK throughout on /api/sync and /identity/connect/token)
• Full re-sync: no effect
• Uninstall/reinstall of the extension: no effect
• Fresh Edge profile (no prior extension cache/state): same crash
• Verified all cipher fields directly in the Postgres database (name, notes, fields, password_history columns, plus username, password, totp, uris/uriChecksum, autofillOnPageLoad, fido2Credentials in the JSON data column) for correct encryption-string format and expected types — everything checked out clean, no malformed entries
• Same account/vault loads correctly via Brave with extension 2026.6.1 (SDK main c5d5bba)
• Workaround confirmed: manually downgrading the Edge extension to 2026.6.1 fixes it completely

Given this reproduces with both SQLite and Postgres backends, and in both the browser extension and the standalone Desktop App, this looks like a genuine regression in the 2026.7.0 client build (shared Rust/WASM SDK) rather than anything server- or database-specific.

[pamperer562580892423]

No need to reproduce anything at this point: #7462

[Pockenfresse]

Confirming this on Firefox — and narrowing it down further

Hit the exact same issue independently before finding this thread — thanks @Zayeen for the clear writeup, this matches my case closely.

My setup:

Vaultwarden 1.36.0 (self-hosted, confirmed latest via /admin)
Web Vault 2026.4.1 (latest)
Firefox extension: 2026.7.0 broken Version 2026.3 works perfekt

Additional data point: I initially suspected a corrupted legacy item (my vault was originally imported from KeePass), so I moved everything to trash, permanently emptied it, and created a single brand-new item manually through the web vault — no import, no automation involved. The extension still crashed with the identical error, now pointing at that one fresh item:

Uncaught Error: invalid type: JsValue(Object({"name":"2.HIfhW7KeaDJfKuSa3jvMnQ==|...", ...})), expected a string
    at bitwarden_wasm_internal_bg.js:6830

This confirms it's not related to any specific item or import history — even data that never touched an import pipeline triggers the crash. Downgrading the extension should fix it for anyone hitting this in the meantime.

I also posted a more detailed report with full console logs in discussion #7334, in case that's useful context.

@BlackDex — is there a tracking issue for this regression against the stable 2026.7.0 release, or is :testing currently the only path forward until it's patched upstream?

[BlackDex]

See #7462

[BlackDex]

And it is fixed in 1.37.0

[JaKe24988]

Can confirm this also affects the Bitwarden Desktop app, not just the browser extension.

• Vaultwarden: 1.36.0
• Web Vault: 2026.4.1
• Desktop app: 2026.7 — also affected
• Browser extension: 2026.7.0 (Firefox) — also affected, matches OP's report exactly
• Same error: invalid type: JsValue(Object(...)), expected a string

So this isn't extension-specific — looks like the same WASM SDK build shipped in both 2026.7 client releases. Downgrading both to 2026.6.x works around it for me too. Web Vault (2026.4.1) is unaffected and works fine as a fallback in the meantime.

[pamperer562580892423]

See #7462 - and #7473

[viniciosbarros]

Adding diagnostic data for the record. The server-side fix (1.37.0) has already been identified, so this is not a support request. I'm posting this because @dani-garcia asked for logs in #7474, and I couldn't find the SDK-side trace or the expanded JsValue payload in any of the related threads (#7462, #7464, #7474, #7476, #7485).

All ciphertext below is redacted. Only the shape is preserved, since that's the relevant part.

Environment

Server	Vaultwarden 1.36.0, self-hosted behind Cloudflare
/api/config	version: 2025.12.0, gitHash: f21a3ada, server.name: Vaultwarden
Web vault	2026.4.1 (bundled with 1.36.0), works correctly
Client	Bitwarden Firefox extension 2026.7.0 (AMO build, 19,055,042 bytes), broken
Browser	Firefox 152.0.6 (Snap package on Ubuntu)
Symptom	Login succeeds, the popup spins indefinitely, and the item list never renders

Reinstalling the extension did not help (as expected, see the persistence note below). Downgrading to 2026.6.1 immediately restored normal operation, matching the reports from other users.

1. SDK-side log (bitwarden_core)

This comes from the extension's own error report, not the browser console. Notice where it stops.

12:50:22.126Z INFO bitwarden_core::key_management::wasm_unlock_state           Getting the user-key from client managed-state in SDK
12:50:22.135Z INFO bitwarden_core::client::internal                           Setting user key with ID Local(LocalId(<REDACTED-UUID>))
12:50:22.135Z INFO bitwarden_core::key_management::account_cryptographic_state Initializing V1 account cryptographic state
12:50:22.139Z INFO bitwarden_core::key_management::local_user_data_key_state   No V2 upgrade token available from state bridge, skipping WrappedLocalUserDataKey migration
12:50:22.141Z INFO bitwarden_core::key_management::local_user_data_key_state   WrappedLocalUserDataKey already exists in state, skipping
12:50:22.141Z INFO bitwarden_core::key_management::local_user_data_key_state   Getting the WrappedLocalUserDataKey from state
12:50:22.148Z INFO bitwarden_core::key_management::crypto                      User crypto initialized successfully
12:50:22.148Z INFO bitwarden_core::client::encryption_settings                 Decrypting organization keys
12:50:22.155Z INFO bitwarden_core::client::encryption_settings                 Successfully decapsulated organization key for org

The trace ends cleanly after organization key decapsulation. Account crypto initialization and organization key unwrapping both succeed. The failure happens later, during cipher deserialization. Nothing in this log indicates an error, which makes it look as though initialization completed successfully.

2. Expanded JsValue exception

In the other threads this usually appears as JsValue(Object(...)). Here is the full object.

Unhandled error in angular Error: Error: invalid type: JsValue(Object({
  "autofillOnPageLoad": null,
  "fido2Credentials": [],
  "fields": [],
  "name": "2.<REDACTED>|<REDACTED>|<REDACTED>",
  "notes": null,
  "password": "2.<REDACTED>|<REDACTED>|<REDACTED>",
  "passwordHistory": [],
  "passwordRevisionDate": null,
  "totp": null,
  "uri": "2.<REDACTED>|<REDACTED>|<REDACTED>",
  "uris": [
    {
      "match": null,
      "uri": "2.<REDACTED>|<REDACTED>|<REDACTED>",
      "uriChecksum": "2.<REDACTED>|<REDACTED>|<REDACTED>"
    }
  ],
  "username": "2.<REDACTED>|<REDACTED>|<REDACTED>"
})), expected a string
    je bitwarden_wasm_internal_bg.js:6830
    Ti bitwarden_wasm_internal_bg.js:8242
    i  bitwarden_wasm_internal_bg.js:8580
    invokeTask   zone.js:431
    onInvokeTask ng_zone.ts:453
    invokeTask   zone.js:430
    runTask      zone.js:161
    y            zone.js:612
  console-log.service.ts:51:17

Two things stand out:

• The object is flattened across two schema levels. name, notes, fields, and passwordHistory belong to the Cipher level, while username, password, totp, uris, fido2Credentials, autofillOnPageLoad, and passwordRevisionDate belong to the Login level. They are all present as siblings.
• Both uri (legacy, singular) and uris (current, array) are present at the same time, carrying the same value.

The deserializer receives this object where it expects a string. All ciphertext is valid type 2 (data|iv|mac), so this appears to be a structural mismatch rather than an encoding issue. That also matches the reports that a newly created item reproduces the same failure.

3. Why reinstalling alone doesn't help, and why a force sync is required

Before changing anything, I inspected the extension's storage on disk.

<profile>/storage/default/moz-extension+++<uuid>^userContextId=4294967295/idb/
  3647222921wleabcEoxlt-eengsairo.sqlite          98 KB   (54 keys, object store "storage-local-data")
  3647222921wleabcEoxlt-eengsairo.files/1        659 KB   (external blob)

The 659 KB external blob is user_<id>_ciphers_ciphers, containing the entire encrypted vault. Its modification time is 09:49 local, while the crash above occurred at 09:50. The extension itself had been reinstalled at 09:47.

This suggests that synchronization completed successfully, the encrypted payload was written to disk, and only then did deserialization fail during the read path. The network, authentication token, and local storage integrity all appear to be intact.

This may also explain the inconsistent reports in #7485. @morskipas observed that reinstalling fixed the issue while logout/login did not, whereas others reported the opposite. The malformed payload is stored in IndexedDB and persists until it is overwritten or removed. Uninstalling removes the entire storage origin, while logout may leave the cached ciphers untouched.

That is why a forced sync after upgrading the server appears to be required rather than optional. This is a hypothesis based on the storage state above. I have not traced the extension's logout path to confirm it.

Status on our side

We have pinned the extension to 2026.6.1 with automatic updates disabled as a temporary workaround. The server upgrade to 1.37.1 is pending. After upgrading, we'll force a sync and then move the extension back to the current release.

I'm happy to provide any additional profile information that would help. I'd rather not share the encrypted vault contents themselves, but I can provide structure, key inventory, timestamps, and additional logs.

[BlackDex]

All clients version v2026.7.0 are incompatible with Vaultwarden v1.36.0 and lower.

If you test any client with v2026.7.0 or higher using 1.36.0 or lower it will fail.

Do not waist your tokens on this!