Overview: 1 vulnerability

WSA Score Severity Issue Vulnerability type Scope Versions Fix Release date
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

WSA-2026-31: [Relay] Bypass of TOTP and denial of service with invalid TOTP received from a relay client.

Vulnerability
CVE
Not available
CVSS vector
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (detail)
CVSS score
7.5 / 10
Severity
high
Vulnerability type
Improper Authentication (detail)
Scope
Relay
Affected versions
2.4 → 4.10.3
Fixed version
4.10.4 () - ChangeLog
Tracker
Not available
Commits
Description
The relay plugin can require a Time-based One-Time Password (TOTP) as secondary authentication factor, when the option relay.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.
The TOTP received is validated with the info 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.
In addition, with the 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.
A remote user knowing the relay password can bypass the TOTP, and get full access to WeeChat through the relay; any remote user able to connect to the relay port, without knowing the relay password, can freeze WeeChat when TOTP is enabled, by sending such commands repeatedly.
With the fix, the TOTP received from a client must have exactly 6 digits, otherwise it is rejected, with both protocols.
In version 5.0.0, the info 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.
Mitigation
There are multiple ways to mitigate this issue: