CVE-2026-53525: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-53525 is a timing-attack vulnerability in WeeChat's relay component that allows an attacker to infer authentication secrets via observable response-time differences during password and TOTP validation. It affects WeeChat versions 0.3.4 through 4.9.0, with the patched version being 4.9.1. The vulnerability was published on May 31, 2026, and carries a CVSS v3.1 base score of 7.4 (High) (GitHub Advisory).

The root cause is the use of non-constant-time string comparison functions (weechat_strcasecmp and strcmp) to verify password hashes and plaintext passwords in src/plugins/relay/relay-auth.c, classified as CWE-208 (Observable Timing Discrepancy) (GitHub Advisory). The string_strcasecmp() function in src/core/core-string.c performs an early exit on the first character mismatch, leaking information about how many characters matched before the comparison failed. For SHA and PBKDF2 hash variants, an attacker controls both the salt and the submitted hash value, enabling a character-by-character oracle attack requiring approximately 1,024 attempts (64 positions × 16 hex characters) to recover a full SHA-256 hash; for plaintext password mode (the default via password_hash_algo = "*"), timing differences leak password characters directly (GitHub Advisory).

Successful exploitation enables authentication bypass against the WeeChat relay interface: an attacker can derive the server's expected password hash character by character and then authenticate without ever knowing the actual password. Integrity and availability of the relay service are both rated High in the CVSS assessment, as a successful attacker gains full relay access and can manipulate or disrupt IRC sessions. The attack is most practical over localhost or LAN where timing differences are statistically measurable, though PBKDF2's ~100ms computation cost per attempt makes that variant harder to exploit than SHA-based or plaintext authentication (GitHub Advisory).

The CVE is currently in Reserved status with no public exploit code confirmed, though the GitHub advisory provides a detailed algorithmic description of the attack methodology (GitHub Advisory). The attack complexity is rated High (CVSS AC:H), reflecting the statistical precision required to measure timing differences reliably. No in-the-wild exploitation, threat actor attribution, or CISA KEV catalog listing has been reported. A Tenable Nessus plugin (ID 337846) was published to detect vulnerable installations (Tenable).

1. Reconnaissance: Identify a WeeChat relay endpoint (default port 9000 for plain, 9001 for SSL) running version 0.3.4–4.9.0 using network scanning tools such as Nmap.
2. Determine authentication mode: Probe the relay to identify whether plaintext, SHA, or PBKDF2 password hashing is in use, as the attack strategy differs slightly per mode.
3. Select a fixed salt: For SHA/PBKDF2 modes, choose a fixed salt S to use across all authentication attempts, ensuring the server computes the same hash each time.
4. Character-by-character timing oracle: Send authentication attempts with salt S and candidate hashes (e.g., "0000...0000", "1000...0000", ..., "f000...0000"), measuring server response times for each. The candidate that takes marginally longer to reject indicates the correct first hex character.
5. Repeat for all positions: Iterate across all 64 character positions of the SHA-256 hex digest, performing up to 16 timed attempts per position (~1,024 total attempts) to reconstruct the full server-computed hash.
6. Authenticate: Send a final authentication request using salt S and the recovered hash to gain full relay access without knowing the underlying password.
7. Plaintext mode shortcut: If password_hash_algo = "*" is active (default), apply the same timing oracle directly against password characters, reducing the search space to the password's character set and length (GitHub Advisory).

• Network: High volume of authentication attempts to the WeeChat relay port (default 9000/9001) from a single source IP, particularly with systematically varying hash values while reusing the same salt value.
• Logs: WeeChat relay logs showing repeated failed authentication attempts with incrementally varying credential payloads; a final successful authentication following a long sequence of failures from the same source.
• Process/Behavior: Unusual statistical patterns in relay authentication timing — defenders monitoring relay auth latency may observe an attacker probing response times with near-identical requests differing only in one character of the submitted hash (GitHub Advisory).

Upgrade WeeChat to version 4.9.1, which replaces non-constant-time comparison functions with a constant-time equivalent to eliminate the timing oracle (GitHub Advisory). As a workaround prior to patching, restrict relay access to trusted networks only (e.g., via firewall rules limiting relay port access to localhost or specific trusted IPs), which significantly reduces an attacker's ability to obtain reliable timing measurements. Disabling the relay plugin entirely (/set relay.network.password "" combined with not loading the relay plugin) eliminates exposure if the relay feature is not required. OpenSUSE has issued a security announcement for updated packages (OpenSUSE).

The vulnerability was reported by researcher TristanInSec and disclosed via GitHub's security advisory system on May 31, 2026 (GitHub Advisory). OpenSUSE issued a security announcement for patched packages, and Tenable published a Nessus detection plugin (ID 337846), indicating routine uptake by the security tooling community (OpenSUSE, Tenable). No significant broader media coverage or notable social media discussion has been identified beyond standard vulnerability tracking.