[BUG] Change data in the web overwritten password saved from Chrome extension #540

New Issue

OVERLORD · 2026-02-04T21:28:02+03:00

OVERLORD commented

2026-02-04 21:28:02 +03:00

Originally created by @yegle on GitHub (Dec 27, 2019).

Subject of the issue

(Note: I'm not sure if this is a bug in the official Chrome extension or in the bitwraden_rs project. But I'm gonna report it here first.)

This is a potential data loss bug that can be easily reproduced, so would appreciate if this can be prioritized.

Your environment

Bitwarden_rs version: 1.13.0-4cec502f
Install method: Docker image
Clients used: Chrome extension
Reverse proxy and version: Pomerium (probably not related)
Version of mysql/postgresql:
Other relevant information:

Steps to reproduce

Add a new entry in the vault. In my case, I created an entry with password simple with login URl https://example.com.
In the web, go to "Tools" then "Weak Passwords Report", you should find example.com in the list as Very Weak.
You click on that entry, you should be at the "EDIT ITEM" page. Keep it open.
Now click on the Chrome extension icon, find example.com, modify the password to complex, save. At this time, you should see "Password history: $NUM" in the Chrome extension.
To make sure the server received this change, in the extension, go to "Settings" -> "Sync" -> "Sync Vault Now".
Now go back to the web, the "EDIT ITEM" page, modify anything on the form (e.g. change username to foo) then save.
Go back to vault in the web, search example.com and check the password

Expected behaviour

The username of the entry should be foo and the password should be complex, with at least one password history with value simple.

Actual behaviour

The username is foo as expected, the password is simple, there's no password history at all. I.e. the password that I saved from the browser extension is gone.

FWIW: this is actually happening to me when I go through weak passwords report one by one and modify the password in a different tab, and accidentally saved the form with modified data in the web UI.

Relevant logs

Originally created by @yegle on GitHub (Dec 27, 2019). ### Subject of the issue (Note: I'm not sure if this is a bug in the official Chrome extension or in the bitwraden_rs project. But I'm gonna report it here first.) **This is a potential data loss bug that can be easily reproduced, so would appreciate if this can be prioritized.** ### Your environment * Bitwarden_rs version: 1.13.0-4cec502f * Install method: Docker image * Clients used: Chrome extension * Reverse proxy and version: Pomerium (probably not related) * Version of mysql/postgresql:  * Other relevant information: ### Steps to reproduce 1. Add a new entry in the vault. In my case, I created an entry with password `simple` with login URl `https://example.com`. 2. In the web, go to "Tools" then "Weak Passwords Report", you should find `example.com` in the list as `Very Weak`. 3. You click on that entry, you should be at the "EDIT ITEM" page. Keep it open. 4. Now click on the Chrome extension icon, find `example.com`, modify the password to `complex`, save. At this time, you should see "Password history: $NUM" in the Chrome extension. 5. To make sure the server received this change, in the extension, go to "Settings" -> "Sync" -> "Sync Vault Now". 6. Now go back to the web, the "EDIT ITEM" page, modify anything on the form (e.g. change username to `foo`) then save. 7. Go back to vault in the web, search example.com and check the password ### Expected behaviour The username of the entry should be `foo` and the password should be `complex`, with at least one password history with value `simple`. ### Actual behaviour The username is `foo` as expected, the password is `simple`, there's no password history at all. I.e. the password that I saved from the browser extension is gone. FWIW: this is actually happening to me when I go through weak passwords report one by one and modify the password in a different tab, and accidentally saved the form with modified data in the web UI. ### Relevant logs

OVERLORD added the enhancement bug low priority labels 2026-02-04 21:28:02 +03:00

OVERLORD closed this issue

2026-02-04 21:28:04 +03:00

OVERLORD commented

2026-02-04 21:28:10 +03:00

@dani-garcia commented on GitHub (Dec 27, 2019):

Okay, I've tried it upstream to see what would happen, and there the result is a password of simple, with the password of complex in the pasword history. We should change it to at least match that behavior.

That said, you are right that neither implementation handles concurrent editing very well.

@dani-garcia commented on GitHub (Dec 27, 2019): Okay, I've tried it upstream to see what would happen, and there the result is a password of simple, with the password of complex in the pasword history. We should change it to at least match that behavior. That said, you are right that neither implementation handles concurrent editing very well.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#540