As concerning as the exploit is, Bitwarden's purported response is even more so; FTA:
> I've reported the issue to Bitwarden previously, however it was marked out of scope as it belongs to one of these categories:
>> Attacks requiring physical access to a user's device
> or
>> Scenarios that are extremely complex, difficult or unlikely when utilizing already compromised administrative accounts, self-hosted server, networks or physical devices which would render much easier and alternate means of compromising the data contained within Bitwarden
> This is however not entirely true: only the device-local encrypted vault data needs to be accessed. If accessing device-local data is outside of the threat model, why are we encrypting these data at all? We might as well store them in plain text.
This seems to depend on the "lock with master password on restart" to be disabled.
In other words, your password fault is unlocked, so yeah it follows that the PIN could be brute-forced.
This is all about the tradeoff between security and convenience. Keeping your vault unlocked is much like keeping your front door unlocked. Yep, its more convenient but it doesn't stop anyone else from wandering in and taking your stuff
If your bitwarden vault is locked then you need the master password, and (hopefully) you can't brute-force that.
> I've reported the issue to Bitwarden previously, however it was marked out of scope as it belongs to one of these categories:
>> Attacks requiring physical access to a user's device
> or
>> Scenarios that are extremely complex, difficult or unlikely when utilizing already compromised administrative accounts, self-hosted server, networks or physical devices which would render much easier and alternate means of compromising the data contained within Bitwarden
> This is however not entirely true: only the device-local encrypted vault data needs to be accessed. If accessing device-local data is outside of the threat model, why are we encrypting these data at all? We might as well store them in plain text.