Hi, just noticed this banner for the first time but also I’m a brand new user to BitWarden Premium user.
I noticed it for my TripAdvisor entry.
Maybe this is because TripAdvisor had some breaches back in 2011 and 2014?
So I went ahead and changed the password and used the BitWarden password generator to create a new password and BitWarden even told me it was strong.
Once I successfully changed the password, I would assume the banner would go away but it did not. I feel like BitWarden should automatically clear this banner when it sees that the user has changed the password, especially if they used the built-in password generator.
I see this in both:
BitWarden Desktop app for MacOS: 2025.12.0 (52522)
Create a clone of the TripAdvisor item, but before saving the clone, change the password back to the old password (if you don’t know the old password, you should be able to look it up by clicking the Password history link in the existing TripAdvisor item before cloning); only change the password that is stored in the cloned item in the vault — do not make a password change on the TripAdvisor site. Is the “At-risk” warning banner now displayed in the cloned item?
Run the three vault health reports again, and look for the cloned TripAdvisor item. Which report(s) does it appear in?
After testing, you can/should delete the cloned version of the TripAdvisor item, and it may also be a good idea to open the Trash folder and permanently delete the clone from the Trash.
P.S. You cross-posted the same comment in another topic, which is against the Community Guidelines.
Ok, I have 734 separate bitwarden accounts, with between 1 and 198 separate microsoft credentials in each account.
When would you like to volunteer to update 734 independent Bitwarden accounts with a new manually created global equivalent domain list for microsoft because the users aren’t going to be able to figure this out on their own.
That would be a no from me unless you want to pay for the dozens (probably more) of man hours of billables trying to coordinate contacting each butwarden user and manually updating each users bitwarden account?
Fixing the dev problem is the solution for my customers, and the 16 million other user install base on the chrome store alone.
To be fair, when I said that it isn’t “that hard”, I was addressing your original concern that the process of adding a second URL would be too difficult for non-technical users to perform correctly (at least that’s how I interpreted your statement that “non-technical users…would never be able to handle this kind of manual work-around”). I wasn’t implying that the process would be efficient for a user (even a technically adept one) who has hundreds of duplicate credentials in their vault; my previous comment merely asserted that I believe non-technical users would have the capacity to understand and correctly execute the process that I described.
If you haven’t already done so, you may want to support the following feature request, which is relevant to the problems you describe:
But I clicked that little Vote button regardless of the efficacy of such actions
Hey, Bitwarden making it take longer, and have more billables loading password lists into spreadsheets and manually deduplicating…I guess I shouldn’t be voting against my pocketbook.
I could probably build the feature in about 15-30mins of vibe coding…but why would I bother. It’s just a waste of my life since Bitwarden couldn’t accept a PR to save it’s corporate existence.
This spooked me, because I saw this today, and I think it’s because it’s a reused password, I do have a password I commonly reuse but only on services running on my home LAN. So today I saw that warning on one of these passwords and was very concerned that there was a keylogger on one of my systems or something.
Frustrating that this hasn’t been fixed. It’s essential to know what is the reason for the flag. I have a few records that are being flagged as “at risk” and it is only because of 2 addresses from the same site (like mobile and desktop site). There’s a big difference between a leaked password and a duplicate one.
The best approach for this scenario is to copy the URLs from one vault item into the other and then deleting the “donor” vault item, so that you have only one vault item per credential.
Beyond making the annoying message go away, it also ensures that when you change the password, it works on both sites with no need to remember to update both vault entries.
I don’t see this on versions 2026.1.x. – But when you experience this, and can document that those new login entries/passwords are not listed in the three corresponding Vault Health Reports (weak / reused / exposed), then you should report it as a potential bug on GitHub (“New issue”).
I came here to add my two cents to this issue. I just now ran into this. And it confused the hell out of me since I dont actually re-use passwords. The item in question, the password is not weak (I tested it on Bitwardens password tester and it reports as strong with centuries to break it), and not in any breech report. I suspect the reason is that for the particular service (internal to my home network), the password is on two different entries for the same service. In this case, its the login to my firewall.Once in my personal vault, and once in my organization (shared with my spouse). I ran the re-used password report and where it used to show none, now it shows 134. So this has to be some kind of bug that was recently introduced.
So, I would also like to vote for two things to be added that most other are also asking for.
It should give a reason a password is at-risk.
There should be a way to disable that warning (either on the entry or globally)
The other thing it did, which is not related to this specific issue but it just started doing at the same time and on the same entry… When I visited the site, it showed me the old entry in orange and the current site in green and asked me if I wanted to update them as if they were different. Thing is… Both the URL’s it displayed to me were identical. So it seems like a nice feature but.. It was wrong..
I am running Self-Hosted Premium (Family) version 2026.2.1 with one “Organization”.
I wanted to add to this that, it would be cool if Bitwarden had some kind of “clean-up” feature to help find and merge “duplicate” entries. What I am finding in my case is that I created an original entry for something. Then later I logged into it, and Bitwarden thought that the existing entry was a “new” entry and a pop-up encouraged me to add the new entry. But all it did was create duplicates that its now complaining about. So I am guessing that while my situation may not be common, I also can’t be the only one thats had this problem after being on Bitwarden for 3+ years or so. A cleanup and de-duplicate function would be a very nice thing to have.
It’s been a few months since this thread was started, but figured I’d chime in. I’ve started seeing the ‘at risk password’ prompt in the Bitwarden Extension on Brave. The thing is, the passwords it’s flagging are long and complex (20 characters minimum, typically, with upper, lower, number and symbol), were generated by Bitwardens generator no less, and not a single one of them has been used at more than one place. Each place I have a login gets its own unique password. So they’re not weak, they’re not reused. So Bitwarden is saying that a ton of unrelated sites have ALL had credential breaches?
@SubnetMask Before you drop a bug report on GitHub: make sure you’re on the latest BW versions (browser extension, desktop app…) – and I would also check the other two reports for “weak” and reused passwords, just in case.
After digging some more into mine… They are all “reused” passwords. They are not exposed or weak. HOWEVER, they are all related to the same sites. For example (made up): https://10.10.10.25/index.php and https://10.10.10.25 . Another made up example:
Same server same site… In the past the reused password report would ignore these. But something has changed in a recent build where now, they are not ignored. That seems to be the case with most of mine.
While checking though, I found one that says the password is reused, and it most certainly is not. The entry or any form of it only exists in one place. So I am going to say there is a bug in the logic they recently introduced.
The better solution in this particular scenario if to put all the URLs on the same vault entry. Beyond eliminating the error, it has the added benefit of only requiring an update in one location when you change the password.
When this is not possible due to different formats in the username, you might consider voting for this feature request: