This page lists all known and fixed security vulnerabilities in version 4.10.3 (back to the list of all versions).
| WSA | Score | Severity | Issue | Vulnerability type | Scope | Versions | Fix | Release date |
|---|---|---|---|---|---|---|---|---|
| WSA-2026-32 | 7.5 | Denial of service with many passwords in command init received from a relay client. | Allocation of Resources Without Limits or Throttling | Relay | 2.8 → 4.10.3 | 4.10.4 | ||
| WSA-2026-31 | 7.5 | Bypass of TOTP and denial of service with invalid TOTP received from a relay client. | Improper Authentication | Relay | 2.4 → 4.10.3 | 4.10.4 |
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).
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.
relay.network.password_hash_iterations), so a single hashed password can block WeeChat even longer.
password or password_hash) and the first TOTP (option totp) are checked, the next ones are ignored.
weechat protocol, see: /relay list and /help relay/help relay.network.allowed_ips/help relay.network.bind_address and /help relay/help relay.network.password_hash_algorelay.network.totp_secret is set: the client sends the TOTP in the command init of the weechat protocol, or in the header x-weechat-totp of the api protocol.
totp_validate, which uses the length of the TOTP received as number of digits, instead of the 6 digits generated by authenticator applications. As a shorter TOTP is the end of the full TOTP, the last 4 or 5 digits of the current TOTP are accepted: a client sending 4 digits has to guess one value out of 10,000 instead of 1,000,000.
weechat protocol, the TOTP is added without any check to the arguments of the info totp_validate, which are separated by commas. With escaped commas in the TOTP, a client can add its own arguments to the info, like the number of TOTP accepted before and after the current one. With a large number, almost any TOTP is accepted, and the validation computes millions of hashes, blocking WeeChat for up to tens of seconds for each command init.
totp_validate has a new optional argument with the number of digits (6 by default), and the TOTP must have exactly this number of digits, containing only digits: this also protects scripts using this info. With older versions, scripts using the info totp_validate must check that the TOTP has the expected number of digits, and contains only digits, before calling the info.
/help relay.network.allowed_ips/help relay.network.bind_address and /help relayweechat protocol, which is the most affected, see: /relay list and /help relay/help relay.network.password