WeeChat Relay Flaw Exposes Auth to Timing Attack

WeeChat, the console-based IRC and relay client common among developers running persistent chat sessions on remote servers, published a dual advisory this week covering two vulnerabilities in the relay module — one on each side of its authentication boundary.

CVE-2026-53525 — Timing side-channel in relay authentication

CVE-2026-53525 carries a CVSS score of 7.4 (High) and affects every WeeChat release from 0.3.1 through 4.9.0 — essentially the project’s entire history.

The relay module lets external clients connect to a running WeeChat instance across a network. It verifies credentials using weechat_strcasecmp and strcmp, both standard string comparison functions that do not execute in constant time. That timing variation is measurable from the network: an attacker can use the observed response differences to recover the server-computed password hash one character at a time, then authenticate using the extracted hash without ever knowing the underlying password.

WeeChat 4.9.1 addresses the issue by replacing those comparisons with constant-time equivalents.

CVE-2026-53524 — Decompression bomb in WebSocket relay handler

CVE-2026-53524 rates CVSS 6.5 (Medium) and covers versions 4.3.0 through 4.9.0. The relay WebSocket handler’s relay_websocket_inflate() decompression function places no upper bound on output size. An authenticated relay user can send a small compressed WebSocket frame — the advisory describes the source as approximately 100 bytes — that decompresses to a volume sufficient to exhaust all available server memory and crash the WeeChat process. The 4.9.1 release caps the decompression output.

Context

Timing attacks against authentication systems are not a new class. The technique has been documented in cryptographic literature for decades and surfaces regularly across network software — it appeared in early SSH implementations, has been patched in OpenSSL and various TLS stacks, and shows up in small auth paths that simply never received a security-focused review. The WeeChat case isn’t surprising; it’s a reminder that even software with a long and healthy security track record can carry the pattern in lower-traffic code paths.

The practical exposure is limited by deployment norms. WeeChat relay mode is disabled by default, and most operators run it behind a VPN or SSH tunnel rather than exposing it directly to the internet. The risk rises materially for anyone running relay mode on an internet-facing port — configurations that exist and are not uncommon among power users who want mobile relay access without a persistent SSH session.

The two CVEs together cover both sides of the authentication gate: CVE-2026-53525 before authentication succeeds, CVE-2026-53524 once an attacker is inside. Neither has a reported public exploit or active exploitation as of this writing.

For related coverage of multi-advisory patch cycles and authentication exploitation, see SiYuan v3.7.4 Patches 11 CVEs, Critical RCE Confirmed and Russian Clusters Exploit OAuth Flows to Hijack Accounts.

What to do

Update to WeeChat 4.9.1. If patching is deferred, disabling the relay plugin eliminates both attack surfaces until a maintenance window is available. For operators running relay exposed to an untrusted network, treat the timing issue as high priority — the CVSS score reflects that the authentication bypass does not require local access or prior foothold.