In Redis 7.0 BZMPOP was introduced allowing to block for any of the provided sets to have at least one element.
However this command introduced a change in command arguments for which the current generic blocking code for zset commands is not considering.

When issuing a bzmpop with timeout and count the command also blocks on the timeout/numkeys/max/min which are not keys.
since the keys might not exist at the time the command is issued it may block on these keys. In case the user will add zset key which matches one of these arguments, it will cause the command to be unblocked and provide the results for this key.
This can also be a potential security issue, since in case the user blocking on the command is not authorized for this new key, it would still get access to view the data.

To reproduce
Client 1:

ACL SETUSER ranshid on +@all ~my* nopass
auth ranshid nopass
bzmpop 100 1 myzset max count 10 <--- blocks here

Client 2:
zadd max 1 one 1 two 3 three

client 1 will be unblocked with this output:

1) "max"
2) 1) 1) "three"
      2) "3"
   2) 1) "two"
      2) "2"
   3) 1) "one"
      2) "1"
(6.81s)

Expected behavior
Client 1 should have been blocked waiting for myzset to be written.

Additional information
In my opinion for the blocking infrastructure we can use the same way we take keys for ACK using getKeysFromCommandWithSpecs
in order to iterate and decide if to block on any of the keys.