It may not be clear to other readers that the following text in your OP is an excerpt from Ambiso’s blog post:
Bitwarden’s response
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.
So I am criticizing Ambiso, not you, when I point out that it makes no sense to claim that it “is however not entirely true” that their issue is for “Attacks requiring physical access to a user’s device” — and then go on to admit that the issue does require physical access to a user’s device.
I would suggest reading what Reddit has to say about this blog post:
https://old.reddit.com/r/cybersecurity/comments/11uj8n4/bitwarden_pins_can_be_bruteforced/
https://old.reddit.com/r/Bitwarden/comments/11vt7ge/came_across_this_article_about_bw_pins_being/
…or for that matter, the responses being posted on Ycombinator:
The bottom line is that if a user defeats key defenses by setting a low-entropy PIN (e.g., 1234), by deliberately disabling the “Lock with master password on browser restart” protection, and by lax device opsec (allowing an attacker to physically access their device), then perhaps they should not be surprised that their local vault may be vulnerable to attack.
A more constructive discussion around the issue of PIN security can be found in this year-old forum topic: