The relay plugin checks the password received from a client in the command init of the weechat protocol, as plain text (option password) or hashed (option password_hash), for example with PBKDF2, which the client can choose in the command handshake (allowed by default, see option relay.network.password_hash_algo), and which computes the hash with the number of iterations set in the option relay.network.password_hash_iterations (100000 by default).
Every option password and password_hash received in the command init is checked, so a single command init can contain thousands of hashed passwords, and force WeeChat to compute as many PBKDF2 hashes in the main loop, before the client is authenticated. As each hash takes several milliseconds to compute, a single command blocks WeeChat for minutes.
In version 2.8, the client chooses the number of iterations (since version 2.9, it is set by the option relay.network.password_hash_iterations), so a single hashed password can block WeeChat even longer.
Any remote user able to connect to the relay port, without knowing the relay password, can freeze WeeChat, by sending such commands repeatedly.
With the fix, only the first password (option password or password_hash) and the first TOTP (option totp) are checked, the next ones are ignored.
A new section in the user's guide describes how to protect the relay against abuse.
Mitigation
There are multiple ways to mitigate this issue:
Do not use the relay with the weechat protocol, see: /relay list and /help relay
Restrict the IP addresses allowed to connect to the relay, see: /help relay.network.allowed_ips
Listen only on a local address or a UNIX domain socket, and connect through a VPN or an SSH tunnel, see: /help relay.network.bind_address and /help relay
Do not allow PBKDF2 hash algorithms, see: /help relay.network.password_hash_algo