Database corruption "database disk image is malformed" due to duplicate primary keys – possibly caused by incorrect system time on a new device #97

New Issue

MrUnknownDE · 2026-04-05T20:30:04+02:00

MrUnknownDE commented

2026-04-05 20:30:04 +02:00

Originally created by @TaoRone on 2/22/2026

Prerequisites

I have searched the existing Closed AND Open Issues AND Discussions
I have searched and read the documentation

Vaultwarden Support String

I'm running a self-hosted Bitwarden instance (Vaultwarden) and recently encountered a database corruption error: database disk image is malformed. After investigation, I suspect the root cause might be related to a new device having an incorrect system time (NTP not synchronized, clock set to the past) during synchronization, leading to duplicate entries with the same UUID.

Has anyone encountered a similar issue? Could an incorrect client time really trigger this kind of duplicate primary key insertion?

What would be the safest way to repair the database (e.g., removing duplicate entries based on the most recent revision date)?

Are there any safeguards that could be implemented in Bitwarden/Vaultwarden to prevent such corruption, such as validating client timestamps or using stronger conflict resolution?

Any guidance or insights would be greatly appreciated. Thank you!

Vaultwarden Build Version

v1.33

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

nginx1.26

Host/Server Operating System

Linux

Operating System Version

No response

Clients

Browser Extension

Client Version

No response

Steps To Reproduce

I used sqlite3 to dump the database and look for issues:

text
sqlite3 db.sqlite3 ".dump" > backup.sql
sqlite3 fix.db < backup.sql
During this process, I found several pairs of rows sharing the same UUID but with different encrypted data and revision timestamps.

Here is an example of two conflicting ciphers entries (sensitive data has been redacted):

sql
INSERT INTO ciphers VALUES('d12ddef9-2f41-4d56-b09c-7ed45e95a5df','2023-04-08 04:11:07.581302684','2025-11-30 05:06:03.152207604','7d4b45db-df2e-468d-9767-ed64e18d066b',NULL,1,'2.rotn3twrTfb/3srs0ibR8w==|...','...','...','{"fido2Credentials":[],"password":"...","passwordRevisionDate":"2023-07-21T17:58:53.531Z","totp":null,"uris":[{"match":1,"uri":"...","uriChecksum":"..."}],"username":"..."}','[{"lastUsedDate":"2023-07-21T17:58:53.531Z","password":"..."}]',NULL,0,NULL);

INSERT INTO ciphers VALUES('d12ddef9-2f41-4d56-b09c-7ed45e95a5df','2023-04-08 04:11:07.581302684','2024-05-01 04:25:24.219123814','7d4b45db-df2e-468d-9767-ed64e18d066b',NULL,1,'2.62ScH8llICZtFJ9bsgmjFA==|...','...','...','{"Password":"...","PasswordRevisionDate":"2023-07-21T17:58:53.531Z","Totp":null,"Uris":[{"Match":3,"Uri":"...","UriChecksum":"..."},{"Match":1,"Uri":"...","UriChecksum":"..."}],"Username":"..."}','[{"LastUsedDate":"2023-07-21T17:58:53.531Z","Password":"..."}]',NULL,0,NULL);
Both records have the same UUID (d12ddef9-2f41-4d56-b09c-7ed45e95a5df).

Their encrypted data (e.g., name, data, password history) are completely different.

The revision timestamps are inconsistent: one is in 2025 (future) and the other in 2024 (past), while the creation date is identical.

The JSON structure in the data column also differs in key casing (lowercase vs. uppercase), suggesting they may come from different client versions or corrupted states.

Expected Result

/

Actual Result

A new device with an incorrect system time (e.g., clock set to a date in the past) might have attempted to sync/update entries. This could have caused the server to accept updates with old timestamps, leading to duplicate rows with the same UUID, eventually corrupting the database.

Logs

Runtime error near line 81: UNIQUE constraint failed: users.email (19)
Runtime error near line 1737: UNIQUE constraint failed: ciphers.uuid (19)
Runtime error near line 1750: UNIQUE constraint failed: ciphers.uuid (19)
Runtime error near line 2004: NOT NULL constraint failed: devices.name (19)
Runtime error near line 2005: NOT NULL constraint failed: devices.name (19)
Runtime error near line 2006: NOT NULL constraint failed: devices.name (19)
Runtime error near line 2030: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19)
Runtime error near line 2032: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19)
Runtime error near line 2034: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19)
Runtime error near line 2040: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19)
Runtime error near line 2044: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19)

Screenshots or Videos

No response

Additional Context

No response

*Originally created by @TaoRone on 2/22/2026* ### Prerequisites - [x] I have searched the existing **Closed _AND_ Open** [Issues](https://github.com/dani-garcia/vaultwarden/issues?q=is%3Aissue%20) **_AND_** [Discussions](https://github.com/dani-garcia/vaultwarden/discussions?discussions_q=) - [x] I have searched and read the [documentation](https://github.com/dani-garcia/vaultwarden/wiki/) ### Vaultwarden Support String I'm running a self-hosted Bitwarden instance (Vaultwarden) and recently encountered a database corruption error: database disk image is malformed. After investigation, I suspect the root cause might be related to a new device having an incorrect system time (NTP not synchronized, clock set to the past) during synchronization, leading to duplicate entries with the same UUID. Has anyone encountered a similar issue? Could an incorrect client time really trigger this kind of duplicate primary key insertion? What would be the safest way to repair the database (e.g., removing duplicate entries based on the most recent revision date)? Are there any safeguards that could be implemented in Bitwarden/Vaultwarden to prevent such corruption, such as validating client timestamps or using stronger conflict resolution? Any guidance or insights would be greatly appreciated. Thank you! ### Vaultwarden Build Version v1.33 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy nginx1.26 ### Host/Server Operating System Linux ### Operating System Version _No response_ ### Clients Browser Extension ### Client Version _No response_ ### Steps To Reproduce I used sqlite3 to dump the database and look for issues: text sqlite3 db.sqlite3 ".dump" > backup.sql sqlite3 fix.db < backup.sql During this process, I found several pairs of rows sharing the same UUID but with different encrypted data and revision timestamps. Here is an example of two conflicting ciphers entries (sensitive data has been redacted): sql INSERT INTO ciphers VALUES('d12ddef9-2f41-4d56-b09c-7ed45e95a5df','2023-04-08 04:11:07.581302684','2025-11-30 05:06:03.152207604','7d4b45db-df2e-468d-9767-ed64e18d066b',NULL,1,'2.rotn3twrTfb/3srs0ibR8w==|...','...','...','{"fido2Credentials":[],"password":"...","passwordRevisionDate":"2023-07-21T17:58:53.531Z","totp":null,"uris":[{"match":1,"uri":"...","uriChecksum":"..."}],"username":"..."}','[{"lastUsedDate":"2023-07-21T17:58:53.531Z","password":"..."}]',NULL,0,NULL); INSERT INTO ciphers VALUES('d12ddef9-2f41-4d56-b09c-7ed45e95a5df','2023-04-08 04:11:07.581302684','2024-05-01 04:25:24.219123814','7d4b45db-df2e-468d-9767-ed64e18d066b',NULL,1,'2.62ScH8llICZtFJ9bsgmjFA==|...','...','...','{"Password":"...","PasswordRevisionDate":"2023-07-21T17:58:53.531Z","Totp":null,"Uris":[{"Match":3,"Uri":"...","UriChecksum":"..."},{"Match":1,"Uri":"...","UriChecksum":"..."}],"Username":"..."}','[{"LastUsedDate":"2023-07-21T17:58:53.531Z","Password":"..."}]',NULL,0,NULL); Both records have the same UUID (d12ddef9-2f41-4d56-b09c-7ed45e95a5df). Their encrypted data (e.g., name, data, password history) are completely different. The revision timestamps are inconsistent: one is in 2025 (future) and the other in 2024 (past), while the creation date is identical. The JSON structure in the data column also differs in key casing (lowercase vs. uppercase), suggesting they may come from different client versions or corrupted states. ### Expected Result / ### Actual Result A new device with an incorrect system time (e.g., clock set to a date in the past) might have attempted to sync/update entries. This could have caused the server to accept updates with old timestamps, leading to duplicate rows with the same UUID, eventually corrupting the database. ### Logs ```text Runtime error near line 81: UNIQUE constraint failed: users.email (19) Runtime error near line 1737: UNIQUE constraint failed: ciphers.uuid (19) Runtime error near line 1750: UNIQUE constraint failed: ciphers.uuid (19) Runtime error near line 2004: NOT NULL constraint failed: devices.name (19) Runtime error near line 2005: NOT NULL constraint failed: devices.name (19) Runtime error near line 2006: NOT NULL constraint failed: devices.name (19) Runtime error near line 2030: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19) Runtime error near line 2032: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19) Runtime error near line 2034: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19) Runtime error near line 2040: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19) Runtime error near line 2044: UNIQUE constraint failed: devices.uuid, devices.user_uuid (19) ``` ### Screenshots or Videos _No response_ ### Additional Context _No response_

MrUnknownDE closed this issue

2026-04-05 20:30:04 +02:00

MrUnknownDE added the bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug labels 2026-04-05 20:30:08 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/vaultwarden#97