[GH-ISSUE #7333] Browser extensions v2026.4.0+ fail with EncString(InvalidTypeSymm) — type 2 encrypted strings have 3 parts (data|iv|mac) instead of standard 2 #35632

Closed
opened 2026-07-13 20:28:28 -05:00 by GiteaMirror · 0 comments
Owner

Originally created by @jr2804 on GitHub (Jun 14, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7333

Description

Browser extensions (Chrome, Firefox, Edge) v2026.4.0+ and Android app fail to load vault entries after successful login. The web vault (v2026.4.1) works fine.

The extensions show successful authentication (user avatar visible) but the vault stays on skeleton loading placeholders indefinitely and never shows entries.

Error

From extension DevTools console:

Unhandled error in angular Error: Error: EncString(InvalidTypeSymm { enc_type: "0", parts: 1 })
    at le (bitwarden_wasm_internal_bg.js:5648)
    at On (bitwarden_wasm_internal_bg.js:6922)
    at i (bitwarden_wasm_internal_bg.js:7260)
    ...
    at getStore (browser-local-storage.service.ts:78)

The same error occurs on Android after clearing all app data and on browser extensions after full reinstall / clear storage.

Environment

  • Vaultwarden version: 1.36.0 (gitHash: f21a3ada, also tested on testing tag d6a3d539 — same issue)
  • Web-vault version: 2026.4.1
  • Database: SQLite
  • Running within container: Yes (Debian)
  • Deployed via: Docker, behind Cloudflare Tunnel
  • Clients: Chrome extension 2026.4.0+, Firefox extension 2026.4.0+, Edge extension 2026.4.0+, Android app latest

Root Cause Analysis

Encryption format mismatch

Vaultwarden's encrypt() function produces type 2 (AesCbc256_B64) encrypted strings with 3 pipe-separated parts (data|iv|mac):

2.ENCRYPTED_DATA|IV|MAC

The Bitwarden specification states that type 2 should have 2 parts (data|iv), while the MAC is only expected for type 0 (AesCbc256_HmacSha256_B64, format: 0.data|iv|mac).

Verified

  1. Profile key (profile.key): type 2 with 3 parts
  2. Profile private key (profile.privateKey): type 2 with 3 parts
  3. All 63 cipher entries: type 2 with 3 parts on name, username, password, notes, custom fields

The Python python-vaultwarden library handles this format leniently, but the new Rust WASM SDK (introduced in Bitwarden extension v2026.4.0+) validates strictly and throws InvalidTypeSymm.

The stack trace confirms the error originates at getStore browser-local-storage.service.ts:78 — the WASM SDK crashes when trying to parse the locally stored encrypted data after a successful API sync.

Why web vault works

The web vault v2026.4.1 uses the older JavaScript-based SDK which is lenient about the type 2 format. The Rust WASM SDK is only used in browser extensions and mobile apps.

Steps to Reproduce

  1. Install Vaultwarden 1.36.0 (Docker image vaultwarden/server:1.36.0)
  2. Create an account and add several password entries via the web vault
  3. Install Bitwarden browser extension v2026.4.0+ (Chrome/Firefox/Edge)
  4. Configure self-hosted server URL
  5. Log in successfully (avatar appears)
  6. Observe: vault stays on skeleton loading placeholders, entries never load
  7. Check browser DevTools console → EncString(InvalidTypeSymm { enc_type: "0", parts: 1 })

Expected Behavior

Browser extensions and Android app should successfully load and display vault entries after login, as the web vault does.

Possible Fix

Vaultwarden's encrypt() function should either:

  • Use type 0 (AesCbc256_HmacSha256_B64) for strings with HMAC (0.data|iv|mac) instead of type 2 with MAC
  • Or type 2 should only produce 2.data|iv (without MAC)
  • Additionally, a data migration may be needed for existing vaults that were encrypted with the non-standard format

Existing Data

Profile key sample: 2.ENCRYPTED|IV|MAC  (3 parts after pipe split)
Profile privateKey: 2.ENCRYPTED|IV|MAC  (3 parts)
All ciphers affected: 63 entries with type 2 + 3 parts on all encrypted fields

Labels

bug, encryption, sdk-compatibility

Originally created by @jr2804 on GitHub (Jun 14, 2026). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7333 ## Description Browser extensions (Chrome, Firefox, Edge) v2026.4.0+ and Android app fail to load vault entries after successful login. The web vault (v2026.4.1) works fine. The extensions show successful authentication (user avatar visible) but the vault stays on skeleton loading placeholders indefinitely and never shows entries. ## Error From extension DevTools console: ``` Unhandled error in angular Error: Error: EncString(InvalidTypeSymm { enc_type: "0", parts: 1 }) at le (bitwarden_wasm_internal_bg.js:5648) at On (bitwarden_wasm_internal_bg.js:6922) at i (bitwarden_wasm_internal_bg.js:7260) ... at getStore (browser-local-storage.service.ts:78) ``` The same error occurs on Android after clearing all app data and on browser extensions after full reinstall / clear storage. ## Environment - Vaultwarden version: 1.36.0 (gitHash: f21a3ada, also tested on testing tag d6a3d539 — same issue) - Web-vault version: 2026.4.1 - Database: SQLite - Running within container: Yes (Debian) - Deployed via: Docker, behind Cloudflare Tunnel - Clients: Chrome extension 2026.4.0+, Firefox extension 2026.4.0+, Edge extension 2026.4.0+, Android app latest ## Root Cause Analysis ### Encryption format mismatch Vaultwarden's `encrypt()` function produces **type 2** (AesCbc256_B64) encrypted strings with **3 pipe-separated parts** (`data|iv|mac`): ``` 2.ENCRYPTED_DATA|IV|MAC ``` The Bitwarden specification states that type 2 should have **2 parts** (`data|iv`), while the MAC is only expected for **type 0** (AesCbc256_HmacSha256_B64, format: `0.data|iv|mac`). ### Verified 1. Profile key (`profile.key`): type 2 with 3 parts 2. Profile private key (`profile.privateKey`): type 2 with 3 parts 3. All 63 cipher entries: type 2 with 3 parts on name, username, password, notes, custom fields The Python python-vaultwarden library handles this format leniently, but the new Rust WASM SDK (introduced in Bitwarden extension v2026.4.0+) validates strictly and throws `InvalidTypeSymm`. The stack trace confirms the error originates at `getStore browser-local-storage.service.ts:78` — the WASM SDK crashes when trying to parse the locally stored encrypted data after a successful API sync. ### Why web vault works The web vault v2026.4.1 uses the older JavaScript-based SDK which is lenient about the type 2 format. The Rust WASM SDK is only used in browser extensions and mobile apps. ## Steps to Reproduce 1. Install Vaultwarden 1.36.0 (Docker image `vaultwarden/server:1.36.0`) 2. Create an account and add several password entries via the web vault 3. Install Bitwarden browser extension v2026.4.0+ (Chrome/Firefox/Edge) 4. Configure self-hosted server URL 5. Log in successfully (avatar appears) 6. Observe: vault stays on skeleton loading placeholders, entries never load 7. Check browser DevTools console → `EncString(InvalidTypeSymm { enc_type: "0", parts: 1 })` ## Expected Behavior Browser extensions and Android app should successfully load and display vault entries after login, as the web vault does. ## Possible Fix Vaultwarden's `encrypt()` function should either: - Use **type 0** (AesCbc256_HmacSha256_B64) for strings with HMAC (`0.data|iv|mac`) instead of type 2 with MAC - Or type 2 should only produce `2.data|iv` (without MAC) - Additionally, a data migration may be needed for existing vaults that were encrypted with the non-standard format ## Existing Data ``` Profile key sample: 2.ENCRYPTED|IV|MAC (3 parts after pipe split) Profile privateKey: 2.ENCRYPTED|IV|MAC (3 parts) All ciphers affected: 63 entries with type 2 + 3 parts on all encrypted fields ``` ## Labels bug, encryption, sdk-compatibility
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#35632