With SASL mechanisms scram-sha-1, scram-sha-256 and scram-sha-512, the IRC plugin does not properly check the data received from the server:
The SASL success (numeric 903 or 907) is accepted even if the server did not send its signature, so the server is not authenticated: a malicious server, or a man-in-the-middle, can impersonate the IRC server without knowing the password.
The iteration count is not checked: a malicious server, or a man-in-the-middle, can send a very low iteration count (for example 1), so that the client proof sent by WeeChat makes an offline dictionary attack on the password cheap, or a very high iteration count, so that WeeChat is blocked for a long time while computing the proof.
The server nonce is not checked: it must start with the nonce sent by the client, as required by RFC 5802.
The purpose of SCRAM is to authenticate both the client and the server without sending the password to the server, so these missing checks defeat the protection expected by users choosing these mechanisms.
Mitigation
There are multiple ways to mitigate this issue:
Connect only with TLS and certificate verification enabled (default), to prevent man-in-the-middle attacks, see: /help irc.server_default.tls and /help irc.server_default.tls_verify
Use the SASL mechanism external with a client certificate, see: /help irc.server_default.sasl_mechanism
Use a strong password, unique for each IRC server, to make an offline dictionary attack ineffective