Skip to content

Browser extension crashes vault sync with invalid type: JsValue(Object(...)), expected a string — large-scale format corruption limited to login.username/login.password, unrelated to import date, org, or a single "rogue" cipher #7495

Description

@death-INDEX1887

Prerequisites

Vaultwarden Support String

Your environment (Generated via diagnostics page)

  • Vaultwarden version: v1.37.0
  • Web-vault version: v2026.6.4
  • OS/Arch: linux/x86_64
  • Running within a container: true (Base: Debian)
  • Database type: SQLite
  • Database version: 3.51.3
  • Uses config.json: true
  • Uses a reverse proxy: true
  • IP Header check: true (X-Real-IP)
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Browser/Server Time Check: true
  • Server/NTP Time Check: true
  • Domain Configuration Check: true
  • HTTPS Check: true
  • Websocket Check: true
  • HTTP Response Checks: true

Config & Details (Generated via diagnostics page)

Show Config & Details

Environment settings which are overridden: DOMAIN, ADMIN_TOKEN

Config:

{
  "data_folder": "data",
  "database_url": "******://***************",
  "icon_cache_folder": "data/icon_cache",
  "attachments_folder": "data/attachments",
  "sends_folder": "data/sends",
  "tmp_folder": "data/tmp",
  "templates_folder": "data/templates",
  "rsa_key_filename": "data/rsa_key",
  "web_vault_folder": "web-vault/",
  "enable_websocket": true,
  "push_enabled": false,
  "push_relay_uri": "https://push.bitwarden.com",
  "push_identity_uri": "https://identity.bitwarden.com",
  "push_installation_id": "***",
  "push_installation_key": "***",
  "job_poll_interval_ms": 30000,
  "send_purge_schedule": "0 5 * * * *",
  "trash_purge_schedule": "0 5 0 * * *",
  "incomplete_2fa_schedule": "30 * * * * *",
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "event_cleanup_schedule": "0 10 0 * * *",
  "auth_request_purge_schedule": "30 * * * * *",
  "duo_context_purge_schedule": "30 * * * * *",
  "purge_incomplete_sso_auth": "0 20 0 * * *",
  "domain": "*****://****************",
  "domain_set": true,
  "domain_origin": "*****://****************",
  "domain_path": "",
  "web_vault_enabled": true,
  "sends_allowed": true,
  "hibp_api_key": "***",
  "user_attachment_limit": null,
  "org_attachment_limit": null,
  "user_send_limit": null,
  "trash_auto_delete_days": null,
  "incomplete_2fa_time_limit": 3,
  "disable_icon_download": false,
  "signups_allowed": true,
  "signups_verify": false,
  "signups_verify_resend_time": 3600,
  "signups_verify_resend_limit": 6,
  "signups_domains_whitelist": "",
  "org_events_enabled": false,
  "org_creation_users": "",
  "invitations_allowed": true,
  "invitation_expiration_hours": 120,
  "emergency_access_allowed": true,
  "email_change_allowed": true,
  "password_iterations": 600000,
  "password_hints_allowed": true,
  "show_password_hint": false,
  "admin_token": "***",
  "invitation_org_name": "Vaultwarden",
  "events_days_retain": null,
  "ip_header": "X-Real-IP",
  "_ip_header_enabled": true,
  "ip_header_trusted_proxies": "local",
  "icon_service": "internal",
  "_icon_service_url": "",
  "_icon_service_csp": "",
  "icon_redirect_code": 302,
  "icon_cache_ttl": 2592000,
  "icon_cache_negttl": 259200,
  "icon_download_timeout": 10,
  "icon_blacklist_regex": null,
  "icon_blacklist_non_global_ips": true,
  "http_request_block_regex": null,
  "http_request_block_non_global_ips": true,
  "disable_2fa_remember": false,
  "authenticator_disable_time_drift": false,
  "experimental_client_feature_flags": "",
  "require_device_email": false,
  "reload_templates": false,
  "extended_logging": true,
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "use_syslog": false,
  "log_file": null,
  "log_level": "info",
  "enable_db_wal": true,
  "db_connection_retries": 15,
  "database_timeout": 30,
  "database_idle_timeout": 600,
  "database_max_conns": 10,
  "database_min_conns": 2,
  "database_conn_init": "",
  "disable_admin_token": false,
  "allowed_iframe_ancestors": "",
  "allowed_connect_src": "",
  "login_ratelimit_seconds": 60,
  "login_ratelimit_max_burst": 10,
  "unauthenticated_ratelimit_seconds": 60,
  "unauthenticated_ratelimit_max_burst": 50,
  "admin_ratelimit_seconds": 300,
  "admin_ratelimit_max_burst": 3,
  "admin_session_lifetime": 20,
  "org_groups_enabled": false,
  "increase_note_size_limit": false,
  "_max_note_size": 10000,
  "enforce_single_org_with_reset_pw_policy": false,
  "dns_prefer_ipv6": false,
  "sso_enabled": false,
  "sso_only": false,
  "sso_signups_match_email": true,
  "sso_allow_unknown_email_verification": false,
  "sso_client_id": "",
  "sso_client_secret": "***",
  "sso_authority": "",
  "sso_scopes": "email profile",
  "sso_authorize_extra_params": "",
  "sso_pkce": true,
  "sso_audience_trusted": null,
  "sso_callback_path": "*****://*********************************************",
  "sso_master_password_policy": null,
  "sso_auth_only_not_session": false,
  "sso_client_cache_expiration": 0,
  "sso_debug_tokens": false,
  "_enable_yubico": true,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null,
  "_enable_duo": true,
  "duo_use_iframe": false,
  "duo_ikey": null,
  "duo_skey": null,
  "duo_host": null,
  "_duo_akey": null,
  "_enable_smtp": true,
  "use_sendmail": false,
  "sendmail_command": null,
  "smtp_host": null,
  "smtp_ssl": null,
  "smtp_explicit_tls": null,
  "smtp_security": "starttls",
  "smtp_port": 587,
  "smtp_from": "",
  "smtp_from_name": "***********",
  "smtp_username": null,
  "smtp_password": null,
  "smtp_auth_mechanism": null,
  "smtp_timeout": 15,
  "helo_name": null,
  "smtp_embed_images": true,
  "_smtp_img_src": "***:",
  "smtp_debug": false,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "_enable_email_2fa": false,
  "email_token_size": 6,
  "email_expiration_time": 600,
  "email_attempts_limit": 3,
  "email_2fa_enforce_on_verified_invite": false,
  "email_2fa_auto_fallback": false
}

Vaultwarden Build Version

1.37.0

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

nginx v2.15.1

Host/Server Operating System

Linux

Operating System Version

Ubuntu 24.04.4 LTS

Clients

Browser Extension

Client Version

v2026.7.0

Steps To Reproduce

I can't yet reproduce this from a fresh vault — it only manifests on a long-lived vault, and I don't know the exact original write path that caused the malformed encoding (see hypothesis below). Steps to reproduce the crash and the diagnosis:

  1. Have a Vaultwarden instance with a personal vault and/or organizations that have been in active use for multiple years (ciphers created/updated across many separate sessions, not a single bulk import).
  2. Run/update the server to Vaultwarden 1.37.0 with web-vault 2026.6.4 (or any web-vault version from 2026.4.1 onward, once the WASM SDK enforces strict EncString parsing).
  3. Log in via a current Bitwarden browser extension (tested: Edge/Chromium, version 2026.7.x — same underlying WASM SDK as Chrome/Firefox).
  4. Observe: after successful authentication and organization-key decapsulation (visible in the console logs), the extension crashes with:
    Unhandled error in angular Error: Error: invalid type: JsValue(Object({...})), expected a string
    The vault never renders; login screen sometimes reappears, sometimes it stays on a blank/loading state.
  5. Note: the Web Vault (same server) loads the exact same data without error — it uses the older, more lenient JS-based parser rather than the WASM SDK.

To reproduce the diagnosis (identify the scope/pattern without decrypting anything):

  1. Take a copy of the server's SQLite database (db.sqlite3), never touch the live file.
  2. Scan the ciphers table's data JSON column for encrypted-string fields (login.username, login.password, name, notes, login.uris[].uri, custom fields, password history) whose format is 2.|| (3 pipe-separated parts) instead of the correct 2.| (2 parts) — this alone doesn't require decryption or the master key, only string-splitting on . and |.
  3. Cross-reference the affected cipher UUIDs against their created_at, organization_uuid, and cipher type to look for a pattern.

Expected Result

All ciphers in the vault should load successfully in the browser extension, identical to how they load in the Web Vault. Encrypted fields written by any official client (including inline autofill "update login" prompts) should always conform to the EncString format the WASM SDK expects (type 2 → 2 pipe-separated parts: data|iv), regardless of when or through which save path they were originally written.

Actual Result

The browser extension (tested on Edge/Chromium) crashes immediately after successful login and organization-key decapsulation, with:

Unhandled error in angular Error: Error: invalid type: JsValue(Object({...})), expected a string

The vault UI never renders — it stays on a blank/loading state or bounces back to the login screen. This is caused by 581 of 1172 ciphers (49.6%) in the database having malformed encrypted strings: type-2 (AesCbc256_B64) values with 3 pipe-separated parts (data|iv|mac) instead of the correct 2 (data|iv).

The corruption is isolated specifically to the login.username (531 occurrences) and login.password (578 occurrences) fields — never name, notes, or uri, even on the same cipher. Affected ciphers span the entire lifetime of the vault (2022-01-17 through 2026-07-22) and appear across the personal vault and all 22 organizations, roughly proportional to their size. All affected ciphers are of type "Login"; no secure notes, cards, or identities are affected.

The Web Vault, using the older lenient JS-based parser instead of the WASM SDK, loads the exact same data without any error.

Logs

--- Browser extension console (Edge/Chromium) ---

WebAssembly is supported in this environment
[BrowserApi] Message sender appears to be internal
WASM SDK loaded in 93ms
State version: 82
[EncryptedMigrationsScheduler] No migrations needed for user <user_uuid>

 INFO initialize_user_crypto: bitwarden_core::key_management::wasm_unlock_state: Getting the user-key from client managed-state in SDK
 INFO initialize_user_crypto:initialize_user_crypto_decrypted_key{user_id=Some(UserId(<user_uuid>))}: bitwarden_core::client::internal: Setting user key with ID Local(LocalId(<local_id>))
 INFO initialize_user_crypto: bitwarden_core::key_management::crypto: User crypto initialized successfully
 INFO set_org_keys: bitwarden_core::client::encryption_settings: Decrypting organization keys
 INFO set_org_keys:decapsulate_org_key{org_id=<org_uuid_1>}: bitwarden_core::client::encryption_settings: Successfully decapsulated organization key for org org_id=<org_uuid_1>
 INFO set_org_keys:decapsulate_org_key{org_id=<org_uuid_2>}: bitwarden_core::client::encryption_settings: Successfully decapsulated organization key for org org_id=<org_uuid_2>
 [... all 22 organization keys decapsulate successfully ...]

Unhandled error in angular Error: Error: invalid type: JsValue(Object({"autofillOnPageLoad":null,"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>="}],"username":"2.<redacted>==|<redacted>=|<redacted>="})), expected a string
    at bitwarden_wasm_internal_bg.js:6830:11
    at [wasm module offset]
    at [wasm module offset]
    at [wasm module offset]
    at [wasm module offset]
    at [wasm module offset]
    at c.invokeTask (zone.js:431:33)
    at Object.onInvokeTask (ng_zone.ts:453:25)

--- Read-only diagnostic script output (against a copy of db.sqlite3, no decryption) ---

Total: 1172 entries, of which broken: 581

Distribution by creation date: spread across 2022-01-17 through 2026-07-22,
no clustering on any single day

Distribution by organization:
  PERSONAL (no organization): 211
  <org_uuid_1>: 134
  <org_uuid_2>: 100
  [... 20 more organizations, 1–22 ciphers each ...]

Distribution by item type:
  Login: 581

Affected field names (across all broken entries):
  password: 578
  username: 531

Date range of ALL entries:     2022-01-17 to 2026-07-22
Date range of BROKEN entries:  2022-01-17 to 2026-07-22

Screenshots or Videos

No response

Additional Context

This looks related to #7334 (EncString(InvalidTypeSymm), browser extensions v2026.4.0+), but the scale and the pattern of affected fields point to something more systemic than a single corrupted cipher.

Why this rules out a single corrupted item:

Given the malformation is isolated to exactly login.username/login.password — and never name/notes/uri on the very same cipher — this doesn't look like data corruption from a single bad import or a rogue third-party tool (which would typically corrupt whichever fields it touches, not consistently spare name/uri across 581 independent entries created over 4+ years).

It looks much more consistent with a specific, narrow write path that has, for years, only ever touched username+password and encoded them incorrectly — e.g. the browser extension's inline "Update existing item?" / "Save login" autofill prompt (which updates just credentials on an existing item, unlike the full item-edit form which rewrites name/uri too). This would explain why the corruption is so widespread yet so field-specific, and why it long went unnoticed (older, lenient client-side parsers tolerated the extra |mac segment).

I don't have visibility into the client-side encryption code to confirm this, but the field-specificity across hundreds of independently-created ciphers seems like a strong lead.

Why "delete and let it recreate" isn't viable here:

I saw the suggestion in another thread to delete the corrupted cipher(s) and let the client recreate them. At this scale (581 login credentials across 22 organizations) that would mean manually re-entering hundreds of passwords — a non-starter, and risky if the same write path reproduces the bug on re-save.

What would help:

  • Confirmation on whether Vaultwarden's server-side handling of these fields differs between the "full cipher save" and "update login" API code paths (or whether this is entirely client-side and specific to a particular save/autofill flow).
  • If confirmed, a data migration to normalize existing type-2 3-part strings would be extremely valuable for large/long-lived vaults like this one — manual per-item repair isn't practical at this scale.

Happy to run additional diagnostics (further metadata queries, non-decrypting format checks) on request — I have a read-only analysis script that doesn't touch the actual ciphertext/master key.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions