You are at risk if someone in your network
(1) is running a poisoning server like "Responder"
(2) and you have your browser set to "autoconfigure", which is the default in most browsers.
For home networks, I would not worry too much about it.
For enterprise / company network situations, there is a bit more explanation needed.
First, the recommendation is to disable "Auto Configuration" in your browsers and specify internet settings manually. This may or may not be feasible in your environment. Personally I would remove LLMNR and Netbios from the clients first, because this is a prerequisite for the attack to work.
Secondly, there is a recommendation to create a fake "WPAD" entry in DNS (e.g. 127.0.0.1) to avoid LLMNR lookups. This recommendation makes sense, but in the real world the implementation is a little weird, because by default Windows DNS blocks "WPAD" queries because of it's builtin blocklist. This is counterproductive, because now the client doesn't get a valid response and uses LLMNR queries (broadcasts) instead to find the local WPAD server.
Now, if a malicious actor is running something like "Responder" in your local network, credentials are immediately lost and the blocklist on the DNS server is actually contributing to the problem.
I may misunderstand something, to me it seems the blocklist was introduced before LLMNR became a thing and this was overlooked by Microsoft. Based on my current real world tests, it would be much better to actually allow WPAD queries on your DNS server, by pointing them to a non-existent IP, like 127.0.0.1.
Here is the outpout from Responder, when WPAD is blocked on the DNS server and the client has to fallback to LLMNR:
[*] [LLMNR] Poisoned answer sent to 10.10.66.55 for name wpad
[*] [MDNS] Poisoned answer sent to 10.10.66.55 for name wpad.local
[*] [MDNS] Poisoned answer sent to 10.10.66.55 for name wpad.local
by adding a "WPAD" entry and disabling the blocklist, this issue is mitigated entirely.