Is this a bug? Odd behavior for entries with custom fields named "password"

I know that bugs should be posted on GitHub, but I’m not sure whether the behavior I saw is a bug, so I’m posting here first.

I was helping my mom log into a website that she doesn’t use often. It reported a password error, so I figured there was a problem on the other end and reset the password for the account. The site confirmed the password had been changed, but still reported a password error when I autofilled the entry. I decided to change the password again. Same behavior.

Then I decided to show the password after Bitwarden autofilled it into the login form. It did not match the new password saved in Bitwarden. This momentarily stumped me. I tried another browser. Same behavior.

I decided to inspect the entry more closely.

Most of her entries were originally imported from another password manager. I noticed that this entry included custom fields. One of them was named “password”, and associated with it was the incorrect password that Bitwarden dutifully autofilled every time I asked it to. It was an old password generated and used by her former password manager.

I deleted said custom field, and Bitwarden immediately began using the password actually saved for the entry.

It would seem that a custom field named “password”, if present for an entry, overrides the actual password field when it comes to autofill.

I have just reproduced this by taking a known good entry in my vault, adding a custom text field named “password”, and typing a dummy password into it. The same thing happened for me.

There is an open GitHub issue about that:

Thank youI

And as I’ve just noted in the bug report, the same behavior happens in the corresponding field when a custom field named “username” is present.

1 Like