Not sure what you mean. Did you delete the other login entry, and double-check that your vault contains no other duplicates?
In my tests, the flags are dynamically updated when you Save the item. Try this as a test: For the one example item where you combined the URIs, copy the password and store it temporarily* in the Notes field or in a hidden custom field; then use the password generator feature in the password field to generate a new, unique password (this is just for testing purposes, no need to change your actual password on the website) — does the warning banner go away when you click Save? Then restore your original password into the login item’s password field, and check if the warning banner re-appears when you click Save again.
* You do not actually need to store your original password in a temporary location, because you can always restore it by copying it from the Password History — but it may give you greater piece of mind if you store a copy of the original password while performing the tests suggested above.
Yes. The warning banner goes away when i change the password and reappears when I restore the “real” password.
Does the Vault check against passwords of deleted items as well? That would explain why this password is flagged as at risk. I changed this password two days ago when I first saw the banner, so i think it is safe to assume the password is not compromised, and i created it with the generator tool in the app.
This is happening for me in the Windows Desktop app
Logging into my bitwarden account and checking the reports shows me that
Either the Windows Desktop app is buggy
Or the bitwarden reports are buggy
Take your pick - mind you, my money is on the desktop app being at fault as it sounds like an “enhancement” that has failed. but please fix it with urgency as it doesn’t inspire confidence and scared the bejesus out of me!
Screenshots would be nice, but at a minimum, please provide some information that might give us a chance to reproduce what you’re observing.
If you’re interested in trying to help get to the bottom if the issue, then I would suggest that you find one login item that has the “at-risk” warning banner but does not appear in any Vault Health Reports, and change the password to a new, randomly generated character string (e.g. 14 characters, all character classes included) — changing it on the website password change form as well as in the vault item. Next, please provide the following information:
Is the “at-risk” warning still displayed in the Desktop app?
What was the previous password? (should be safe to share in public now that you’ve changed the password)
The not recent update version on my laptop win11 doesn’t give any at risk notification, the version updated on my desktop does it on 99% of my passwords I’m 100% sure none of these very long unique passwords are at risk (they didn’t got leaked or are known in any breach dataset)
Laptop 2025.11.2
Desktop 2025.12.0
None of the ‘‘at risk’’ passwords in the desktop app are found in my vault health report.
What’s happening I think is because I have two entries for the same login account
Example one is for an app login other for website (or two different domains same account use) desktop app sees this as ‘‘double’’ use password, but I cannot have only one entry for a specified account login. It would break one or the other.
Most flag I have seen are only because same password on different account entries, it looks at the password not the name or domain/app.
But I also see passwords flagged that I cannot find being double used, weak or leaked, something is triggering it.
I understand the flag as being but it’s a bit overkill in my case.
*I also see that the desktop app is flagging shared accounts as being used as double password, one is my main vault and the double in the shared vault.
Then an “at-risk password” flag is expected, and the corresponding login items are expected to be included in the Re-Used Passwords Report.
Why can’t you consolidate both entries into one? Copy the website string from one entry, and then edit the other entry, click Add Website, and paste the copied string into to “Website (URI) 2” field; don’t forget to clcik Save.
Can you provide some more information about these? To help us determine if there is an actual bug, I would suggest that you find one login item that has the “at-risk” warning banner but does not appear in any of the three Vault Health Reports, and change the password to a new, randomly generated character string (e.g. 14 characters, all character classes included) — changing it on the website password change form as well as in the vault item. Next, please provide the following information:
Is the “at-risk” warning still displayed in the Desktop app?
What was the previous password? (should be safe to share in public now that you’ve changed the password)
This was poorly communicated to users. ;? I appreciate the intent, but having Very Basic information about Why a warning is popping up should be the #1 Function of Any new warning.
This new ‘feature’ nagware should include opt-out for reused and weak.
Many of us have dozens of lab only vm’s and services that will never ever be on the public internet.
The alternative is to have a well intentioned alert that desensitizes users to the point that the alert is ignored.
Basically the password is not at-risk in my environment and I tire of false alerts.
A well maintained domain-equivalence list in Bitwarden would dramatically reduce duplicate login creation and confusion - especially for non-technical users which would never be able to handle this kind of manual work-around.
What’s frustrating is that people have already proposed fixes eg:
but those PRs aren’t being reviewed in a reasonable timeframe. Waiting 8+ months for a ~19-character change highlights a code governance and delegation problem, not a technical problem.
I don’t disagree with what you’ve expressed about the equivalent domains (and about delays in review of PR contributions), but adding the second URI is not really that hard: just search for the non-matching item and use the “Autofill” option in the Options menu for that item; the user will then be prompted to “Autofill and add this website”.
This is dysfunctional and fundamentally broken foolishness i.e. claiming something is at risk without providing any verifiable sources for this, yet again seriously makes me question why I pay for Bitwarden! Every time I reach out for support on product that isn’t working for me it gets routed into “feature requests”. I can’t even vote on those because your sites seem to be completely disconnected from each other!
The fact that I’m a paying customer should be enough to validate my voice! Please fix the rampant stupidity of this and do better Bitwarden.
Hi @Regain3764, rest assured the team is already working on providing more context for the alerts, so thank you for providing the feedback. In the meantime, you can review more information in the Vault Health Alerts in the web app.
Add Website, and paste the copied string into to “Website (URI) 2” field; don’t forget to clcik Save.