Decryption error / vault not synchronizing on any client

[770grappenmaker]

Clients I have tested: Bitwarden Extension, the Vaultwarden web interface, Bitwarden on Mobile. All give a very similar error (in the logs, the UI gives a generic error or keeps loading indefinitely):

Unhandled error in angular Error: Error: EncString(InvalidTypeSymm { enc_type: "1", parts: 3 })
    gn bitwarden_wasm_internal_bg.js:6676
    mo bitwarden_wasm_internal_bg.js:8035
    a bitwarden_wasm_internal_bg.js:8370
    invokeTask zone.js:431
    onInvokeTask ng_zone.ts:453
    invokeTask zone.js:430
    runTask zone.js:161
    y zone.js:612
    invokeTask zone.js:519
    invoke zone.js:504
    0 zone.js:1778

This seems related to other breakages, for example #7607, however just downgrading the extension does not work, neither does swapping over to the testing tag. I believe what might've happened is that an invalid record made it into the database, there does not seem to be any database corruption when comparing to backups, logging in and out works fine.

Creating a new user and using its vault also works.

Edit: I have restored a database backup, which solved the problem, diffing the database, the only differing record is (apart from some details in the users and devices tables which do not seem relevant), in the ciphers table:

<uuid>	2026-08-20 21:10:31.545592	2026-08-20 21:10:31.557131	<user uuid>	\N	1	2.<redacted>|<redacted>|<redacted>	\N	[]	{"totp":null,"uris":[{"uriChecksum":"2.<redacted>|<redacted>|<redacted>","match":null,"uri":"2.<redacted>|<redacted>|<redacted>"}],"username":"2.<redacted>|<redacted>|<redacted>","password":"2.<redacted>|<redacted>|<redacted>","passwordRevisionDate":null}	\N	\N	0	\N

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.37.1
• Web-vault version: v2026.6.4
• OS/Arch: linux/x86_64
• Running within a container: true (Base: Debian)
• Database type: PostgreSQL
• Database version: PostgreSQL 18.6 on x86_64-alpine-linux-musl, compiled by cc (Alpine 15.2.0) 15.2.0, 64-bit
• Uses config.json: false
• 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

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": null,
  "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": false,
  "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": true,
  "sso_only": true,
  "sso_signups_match_email": true,
  "sso_allow_unknown_email_verification": false,
  "sso_client_id": "****************************************",
  "sso_client_secret": "***",
  "sso_authority": "*****://*********************************************",
  "sso_scopes": "openid profile email offline_access",
  "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": "**********",
  "smtp_ssl": null,
  "smtp_explicit_tls": null,
  "smtp_security": "off",
  "smtp_port": 25,
  "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": true,
  "email_token_size": 6,
  "email_expiration_time": 600,
  "email_attempts_limit": 3,
  "email_2fa_enforce_on_verified_invite": false,
  "email_2fa_auto_fallback": false
}

[BlackDex]

Any idea which client might have added this entry?
Did you tested a third party client maybe?

[770grappenmaker]

Fairly certain I added this with the Bitwarden Firefox extension, manually. Is there anything clearly wrong with the entry to your knowledge?

[BlackDex]

Not from my quick look at it no.

[hoangperry]

EncString(InvalidTypeSymm { enc_type: "1", parts: 3 }) is the WASM crypto layer refusing a stored cipher string, and it's almost certainly part of the same 2026.8.0 client wave as #7607 — a buggy client wrote an entry the decryptor now can't parse.

What the error means precisely: an EncString is <type>.<base64 parts…>. Type 1 is AesCbc128_HmacSha256, whose valid form has 3 parts (iv.ct.mac). So "type 1, parts 3" looks structurally right — which means the rejection is about the parts' contents/lengths for that type (e.g. a 256-bit-derived value stamped with the 128-bit type tag, or an empty MAC), not the count. In plain terms: a client serialized a cipher with a mismatched type byte, and every client that later reads it — extension, web vault, mobile — chokes on that one bad record, which is exactly why it fails "on all clients."

To recover:

1. First, get onto fixed code: run the vaultwarden/server:testing image (the 2026.8.x server fix), and use a client version that isn't in the broken 2026.8.0 range — that stops new bad entries from being written.
2. Find the poisoned record. BlackDex's question — which client added it — matters because the fix is to identify and delete/re-create that one entry. The blunt way: sqlite3 db.sqlite3 "SELECT uuid, type FROM ciphers ORDER BY updated_at DESC LIMIT 20;" and correlate the most recent writes with when sync broke; the entry created by the 2026.8.0 client is the culprit.
3. Once identified, delete that single cipher (or restore it from a pre-breakage db.sqlite3 backup) — sync returns for the rest of the vault immediately.

If you can tell BlackDex which client/version created the newest entries before it broke, that's the datapoint that helps them pin the client-side serialization bug at the source.

[770grappenmaker]

I don't really appreciate the AI slop answer, but thanks for trying. The interesting part is that the faulty entry has enctype 2, so I'm not sure if your answer makes sense. Either way, the testing branch is irrelevant now as a new version, 1.37.2, has been released with the fixes from the testing branch. As I said, I have deleted an entry now and my vault works again, the only reason I have not resolved the discussion is because there might be an underlying issue still worth investigating, and I have not done that yet. If you read my post, you would've known I am using PostgreSQL, not Sqlite. The client that wrote the record is the Bitwarden browser extension on Firefox, most likely version 2026.8.0, but the exact version is unknown due to auto updates. I have not been able to reproduce the issue since either, so, needs investigation.

[770grappenmaker]

Because I have rotated the password already, I felt comfortable sharing the ciphertext, which I then later redacted so it would have less of a chance of being scraped for eternity, so if you want to read the real faulty record, look into my edit history on the original post.