This page lists all known and fixed security vulnerabilities in stable releases.
The security vulnerabilities introduced during development of a version and fixed before a stable release are not mentioned.
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
Credit
The issue was discovered by Acts1631.
WSA-2026-31: [Relay] Bypass of TOTP and denial of service with invalid TOTP received from a relay client.
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:
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 use the relay with the weechat protocol, which is the most affected, see: /relay list and /help relay
Use a strong password for the relay, unique and not shared with other services, see: /help relay.network.password
WSA-2026-30: [Xfer] Incoming files and chats auto-accepted from a nick on the wrong server.
The option xfer.file.auto_accept_nicks is a list of nicks for which incoming files and chats are automatically accepted, with the format server.nick (for a specific server) or nick (for all servers).
For the format server.nick, only the beginning of the server name is compared, so the nick is also auto-accepted on any other server whose name starts with the same chars.
For example with libera.alice, files and chats sent by nick alice are automatically accepted on servers libera, libera2 or libera_test.
On these other servers, any user able to use this nick (which may not be registered there) can send files that are automatically saved in the download directory, or start DCC chats, without confirmation.
Mitigation
There are multiple ways to mitigate this issue:
Keep the option xfer.file.auto_accept_nicks empty (default), see: /help xfer.file.auto_accept_nicks
Check that no server name in this option is the beginning of another server name, see: /server list
WSA-2026-29: [Relay] Missing check of the number of hash iterations received from a remote relay.
When connecting to a remote relay (command /remote), WeeChat sends a handshake request and the remote replies with the password hash algorithm and the number of hash iterations to use for authentication.
The number of iterations is not checked: a malicious remote, or a man-in-the-middle when the connection is not secured with TLS, can send a huge number of iterations (up to about 2 billion), so that WeeChat is blocked for a very long time while computing the password hash with the algorithm pbkdf2+sha256 or pbkdf2+sha512.
With the fix, the number of iterations must be between 1 and 1000000 (the range allowed in option relay.network.password_hash_iterations), otherwise the handshake fails and WeeChat disconnects from the remote.
Mitigation
There are multiple ways to mitigate this issue:
Connect only to trusted remote relays
Connect only with TLS (URL starting with https://) and certificate verification enabled (default), to prevent man-in-the-middle attacks, see: /help remote and option relay.remote.xxx.tls_verify
WSA-2026-28: [Xfer] Missing checks of the resume position received in DCC RESUME and DCC ACCEPT.
When a DCC file transfer is resumed (option xfer.file.auto_resume, enabled by default), WeeChat sends a DCC RESUME message with the size of the partial file already received, and the remote peer replies with a DCC ACCEPT message containing the position to resume from.
The position received in DCC ACCEPT is not checked against the position sent by WeeChat, and it replaces it:
With a position equal to the file size, the transfer is immediately marked as successfully completed: the truncated partial file is kept as if it was complete, and its temporary suffix (option xfer.file.download_temporary_suffix) is removed.
With any other position, the data received is appended to the partial file at the wrong offset, so the file received is corrupted.
The transfer is identified only by its port, so a DCC ACCEPT message sent by another IRC user knowing the port can have the same effect.
In addition, the position received in DCC RESUME and DCC ACCEPT is not parsed strictly: an invalid value is not rejected, and when sending a file, a position greater than or equal to the file size is accepted.
Mitigation
There are multiple ways to mitigate this issue:
Disable the automatic resume of file transfers: /set xfer.file.auto_resume off
Keep the automatic accept of incoming files disabled (default) and accept files only from trusted users, see: /help xfer.file.auto_accept_files
Check the size or the checksum of files received after a resumed transfer
Credit
The issue was discovered by Acts1631.
WSA-2026-27: [Relay] Denial of service with huge IRC messages received from a relay client.
The relay plugin does not limit the length of IRC messages received from a client connected with the irc protocol: each message is fully parsed, including all its parameters, before the client is authenticated.
A message of a few megabytes with millions of parameters blocks WeeChat for a long time while it is parsed, and the memory used during parsing is much greater than the size of the message (hundreds of megabytes).
Any remote user able to connect to the relay port, without knowing the relay password, can freeze WeeChat and cause high CPU and memory usage, by sending such messages repeatedly.
With the fix, IRC messages longer than 4096 bytes are ignored and WeeChat replies with numeric 417 (ERR_INPUTTOOLONG), like IRC servers do.
Mitigation
There are multiple ways to mitigate this issue:
Do not use the relay with the irc 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, see: /help relay.network.bind_address and /help relay
Credit
The issue was discovered by Acts1631.
WSA-2026-26: [IRC] Missing checks in SASL authentication with SCRAM mechanisms.
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
Credit
The issue was discovered by Joseph Bisch.
WSA-2026-25: [IRC] Evaluation of untrusted strings received from the IRC server or an IRC URL.
Some values coming from untrusted sources are evaluated, so a string like ${...} in these values is replaced by the evaluated expression, for example secured data (${sec.data.xxx}), an environment variable (${env:XXX}) or the result of other expressions.
This happens in the following cases:
Channel names saved automatically in server option autojoin when the option autojoin_dynamic is enabled (WeeChat ≥ 3.5): a channel name may come from the server, for example a channel forward with numeric 470; the channel name is evaluated when the server option autojoin is used.
Server options addresses, nicks, password and autojoin set from an IRC URL (irc://...) given on command line or with command /connect (WeeChat ≥ 0.4.2): the URL may be untrusted, for example when WeeChat is the handler of irc:// links.
Variables $nick, $channel and $server in commands /allchan, /allpv and /allserv (WeeChat ≥ 3.0): they are replaced before the command is evaluated, and nick and channel names come from the server.
A malicious IRC server, or any user able to forward a channel or to send a private message, could disclose secured data (for example passwords) or environment variables, sent back to the server in a JOIN or another command, or cause high CPU and memory usage with expressions like ${repeat:...}.
Mitigation
There are multiple ways to mitigate this issue:
Keep the server option autojoin_dynamic disabled (default) and check that the server option autojoin does not contain ${, see: /help irc.server_default.autojoin_dynamic
Do not connect to untrusted IRC URLs (irc://...) and do not use WeeChat as handler of irc:// links
Do not use variables $nick, $channel and $server in commands /allchan, /allpv and /allserv
Credit
The issue was discovered by Joseph Bisch.
WSA-2026-24: [Relay] Missing size limit for HTTP headers received from a client.
When receiving an HTTP request from a client, the Relay plugin keeps all the header lines received until the end of headers is found.
There is no limit for the allocated buffer, and this happens before the client is authenticated.
A malicious unauthenticated client sending an unlimited number of header lines can lead to memory exhaustion and the WeeChat process can be killed by the OOM killer.
Mitigation
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload.
Credit
The issue was discovered by smaeljaish771.
WSA-2026-23: [Core] Heap buffer overflow in charset conversion.
The output buffer used for charset conversion was allocated with 4 bytes per input byte, but some charsets like TSCII produce more (up to 12 bytes), and the replacement char "?" for invalid chars was written without checking the remaining size, so the output buffer could overflow.
For example a malicious IRC server, or any user sending a message on a channel, could trigger the overflow when the decode charset is set to TSCII.
Note: the default decode charset iso-8859-1 is not affected.
Mitigation
Do not use charset TSCII for decoding: check option charset.default.decode and the options in section "decode" of charset plugin, see: /help charset.
Credit
The issue was discovered by nexrin.
WSA-2026-22: [Relay] Heap buffer overflow in path of hdata sent to clients with "weechat" protocol.
The path of hdata returned to the client with the "weechat" protocol is built in a buffer allocated with twice the length of the path received, but a variable name can be replaced by a hdata name more than twice longer (for example "next_nick" replaced by "irc_channel_speaking"), so that an authenticated client can write out of bounds with a path containing many such variables.
Mitigation
There are multiple ways to mitigate this issue:
Remove all relays with protocol "weechat", see: /help relay
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload
Credit
The issue was discovered by smaeljaish771.
WSA-2026-21: [IRC] Heap buffer overflow in nick prefixes after a reconnection.
When the IRC server sends an empty PREFIX in message 005 and the connection is lost before message 001, the nicks are kept with 1-byte prefixes while the default prefix chars ("@+") are restored on reconnection, so that the next prefix set on a nick (for example with message 353) is written out of bounds.
Note: a "normal" IRC server should not send an empty PREFIX in message 005, so the problem should be limited to malicious IRC servers.
Mitigation
There is no known mitigation.
The upgrade to the latest stable version is highly recommended.
Credit
The issue was discovered by smaeljaish771.
WSA-2026-20: [Relay] Missing size limit of data queued for sending to clients.
When queuing data of sending to clients, the Relay plugin builds a partial buffer.
There is no limit for the allocated buffer.
A malicious unauthenticated client sending PING control frames can can lead to memory exhaustion and the WeeChat process can be killed by the OOM killer.
Mitigation
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload.
Credit
The issue was discovered by Acts1631.
WSA-2026-19: [Relay] Missing rejection of invalid websocket frames.
The relay plugin fails to reject invalid websocket frames.
A malicious client sending invalid websocket frames can lead to memory exhaustion and the WeeChat process can be killed by the OOM killer.
Mitigation
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload.
Credit
The issue was discovered by Acts1631.
WSA-2026-18: [Relay] Missing size limit for the unterminated Relay text message received from a client.
When receiving a text message from a client, the Relay plugin builds a partial buffer until the end of text is found.
There is no limit for the allocated buffer.
A malicious client sending large amount of data without end of text can lead to memory exhaustion and the WeeChat process can be killed by the OOM killer.
Mitigation
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload.
Credit
The issue was discovered by Acts1631.
WSA-2026-17: [Xfer] Bypass of user authorization for start of DCC file transfer.
When receiving part of Xfer chat message, the Xfer plugin builds a partial buffer until the end of message is found.
There is no limit for the allocated buffer.
A malicious client sending large amount of data without end of message can lead to memory exhaustion and the WeeChat process can be killed by the OOM killer.
Mitigation
Unload xfer plugin with command: /plugin unload xfer and see: /help weechat.plugin.autoload.
Credit
The issue was discovered by Acts1631.
WSA-2026-15: [Xfer] Write of DCC file received outside of configured download path.
When receiving a DCC file, the filename may contain directory separator that is not the platform-native one (for example "/" received on Windows or "\" received on Linux). This separator may be interpreted as a directory separator, so the file could be written outside of the configured download path.
Xfer never overwrites existing files, so if a file exists with the same name, a suffix like ".1" is appended to the filename.
Mitigation
Unload xfer plugin with command: /plugin unload xfer and see: /help weechat.plugin.autoload.
Credit
The issue was discovered by Acts1631.
WSA-2026-14: [Relay] Use-after-free and double free when a remote relay sends an event with an array as body.
A malicious (or compromised) relay remote can send a "buffer_closed" event with an array, causing a use-after-free (read and write) followed by a double free, in the relay plugin.
Note: if the remote is a trusted WeeChat, the problem does not happen, as WeeChat itself never sends an array in the "buffer_closed" event.
Mitigation
Always connect to a trusted WeeChat remote.
Credit
The issue was discovered by Mohammed Arib (arib06).
WSA-2026-13: [IRC] Use-after-free in the irc plugin when a batched message disconnects the server.
When a batch message is received and one of the messages causes a disconnection from the server, the remaining messages are reading data that is already freed.
When writing a log file, a specific char used internally as separator may be used to forge a new path that can be outside the path configured by the option logger.file.path.
Mitigation
There is no known mitigation.
The upgrade to the latest stable version is highly recommended.
Credit
The issue was discovered by Mohammed Arib (arib06).
WSA-2026-10: [Relay] Authentication bypass in Relay plugin, protocols "api" and "weechat".
The messages received on "handshake" endpoint, which does not require authentication, are not freed if the content is not a JSON object (for example an array or any other JSON type).
A malicious client can send large arrays and cause memory exhaustion. The WeeChat process can be killed by the OOM killer.
Mitigation
There are multiple ways to mitigate this issue:
Remove all relays with protocol "api", see: /help relay
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload
Secure relay to allow only trusted IP addresses, see: /help relay.network.allowed_ips
Credit
The issue was discovered by Sajda Kabir.
WSA-2026-8: [Relay] Buffer overflow in dump of Relay data.
When receiving a DCC file, the filename built contains the remote nick (the option xfer.file.use_nick_in_filename is on by default).
If the nick contains special characters, the file could be written outside of the configured download path.
Xfer never overwrites existing files, so if a file exists with the same name, a suffix like ".1" is appended to the filename.
Mitigation
Turn off option to include nick in filename: /set xfer.file.use_nick_in_filename off.
Credit
The issue was discovered by aizu-m.
WSA-2026-5: [IRC] Buffer overflow when receiving a DCC file.
When receiving part of websocket frame, HTTP message or HTTP body, the Relay plugin builds a partial buffer until the end of data is found.
There is no limit for the allocated buffer.
A malicious client sending large amount of data without end of websocket frame or HTTP message/body can lead to memory exhaustion and the WeeChat process can be killed by the OOM killer.
Mitigation
There are multiple ways to mitigate this issue:
Remove all relays, see: /help relay
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload
Secure relay to allow only trusted IP addresses, see: /help relay.network.allowed_ips
WSA-2026-3: [IRC] Missing size limit for the unterminated IRC message or isupport value (message 005).
When receiving data on the socket, the IRC plugin builds a partial message until "\r\n" is found.
There is no limit for the allocated message.
A malicious server sending large amount of data without end of message ("\r\n") can lead to memory exhaustion and the WeeChat process can be killed by the OOM killer.
Mitigation
There is no known mitigation.
The upgrade to the latest stable version is highly recommended.
WSA-2026-2: [API, Relay] Non-constant time password/hash comparison.
WeeChat uses non-constant time password/hash comparison in the Relay plugin and in TOTP validation.
This could allow an attacker to guess a password, a hash or a TOTP and bypass relay authentication.
Mitigation
There are multiple ways to mitigate this issue:
Remove all relays, see: /help relay
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload
Secure relay to allow only trusted IP addresses, see: /help relay.network.allowed_ips
Credit
The issue was discovered by Tristan Madani (TristanInSec).
WSA-2026-1: [Relay] Missing size limit for the decompressed websocket frame in relay plugin, protocol "api".
When decompressing a websocket frame received from a Relay client with "api" protocol and permessage-deflate enabled, WeeChat allocates memory without upper limit.
In case of highly compressed frame, this can lead to memory exhaustion and the WeeChat process can be killed by the OOM killer.
A crash happens when decoding a malformed HTTP message in relay plugin, protocol "api".
This happens even if the client is not authenticated, the HTTP message is parsed before the authentication.
Mitigation
There are multiple ways to mitigate this issue:
Remove all relays with protocol "api", see: /help relay
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload
Secure relay to allow only trusted IP addresses, see: /help relay.network.allowed_ips
WSA-2025-7: [Core] Buffer overflow in range of chars in evaluated expressions.
Buffer overflow in function util_parse_time when the received date/time has no date and a length of 117 or more chars.
It can be an issue in IRC plugin, where the "time" tag received in IRC messages is parsed using this function.
Mitigation
There is no known mitigation.
The upgrade to the latest stable version is highly recommended.
WSA-2025-3: [Core] Integer overflow in conversion of version to an integer number.
Integer overflow happens in conversion of a version as string to an integer number, if the version is greater than 0x7FFFFFFF (127.255.255.255), so if the version is at least 0x80000000 (128.0.0.0).
Mitigation
There is no known mitigation.
The upgrade to the latest stable version is highly recommended.
WSA-2025-2: [Core] Integer overflow in base32 decode/encode functions.
An integer overflow can happen when looping over items in a list.
This can only happen in rare conditions on 32 and 64-bit systems, as the list must contain more than 2,147,483,647 elements.
On 16-bit systems, this happens with a list that contains more than 32,767 elements.
Mitigation
There is no known mitigation.
The upgrade to the latest stable version is highly recommended.
Credit
The issue was discovered by Yiheng Cao.
WSA-2022-1: [IRC, Plugins] Possible man-in-the-middle attack in TLS connection to servers.
After changing the options weechat.network.gnutls_ca_system or weechat.network.gnutls_ca_user, the TLS verification function is lost.
Consequently, any connection to a server with TLS is made without verifying the certificate, which could lead to a man-in-the-middle attack.
Connection to IRC servers with TLS is affected, as well as any connection a server made by a plugin or a script using the function hook_connect.
Mitigation
After changing options weechat.network.gnutls_ca_system or weechat.network.gnutls_ca_user, you must restart WeeChat.
WSA-2021-1: [Relay] Crash on malformed websocket frame in relay plugin.
A crash happens when decoding a malformed websocket frame in relay plugin.
This happens even if a password is set in relay plugin, the malformed websocket frame can be received before the authentication of the client.
Mitigation
There are multiple ways to mitigate this issue:
Remove all relays, see: /help relay
Unload relay plugin with command: /plugin unload relay and see: /help weechat.plugin.autoload
Secure relay to allow only trusted IP addresses, see: /help relay.network.allowed_ips
Credit
The issue was discovered by Stuart Nevans Locke.
WSA-2020-3: [IRC] Buffer overflow on new IRC message 005 with nick prefixes.
A buffer overflow happens when a new IRC message 005 is received with longer nick prefixes.
Note: a "normal" IRC server should not send again a message 005 with new nick prefixes, so the problem should be limited to malicious IRC servers.
Mitigation
There is no known mitigation.
The upgrade to the latest stable version is highly recommended.
Credit
The issue was discovered by Stuart Nevans Locke.
WSA-2020-2: [IRC] Crash on malformed IRC message 352 (WHO).
Date/time conversion specifiers are expanded after replacing buffer local variables in name of log files. In some cases, this can lead to an error in function strftime and a crash caused by the use of an uninitialized buffer.
Mitigation
You can unload the logger plugin, thus stopping recording of all buffers: /plugin unload logger.
Credit
The issue was discovered by Joseph Bisch.
WSA-2017-1: [IRC] Buffer overflow when receiving a DCC file.
Strings are built with uncontrolled format when IRC commands are redirected by relay plugin. If the output or redirected command contains formatting chars like "%", this can lead to a crash of WeeChat.
Mitigation
You can remove all relays of type "irc", see /help relay.
WSA-2013-2: [IRC] Crash on send of unknown commands to IRC server.
Untrusted command for function hook_process could lead to execution of commands, because of shell expansions (so the problem is only caused by some scripts, not by WeeChat itself).
Mitigation
Remove/unload all scripts calling the API function hook_process.