CVE-2026-26206: 
Wazuh Server vulnerability analysis and mitigation

CVE-2026-26206 is an API brute-force protection bypass vulnerability in Wazuh's server API, caused by a race condition in login attempt tracking. It affects Wazuh versions 4.0.0 through 4.14.3, allowing unauthenticated attackers to send concurrent authentication requests to the POST /security/user/authenticate endpoint and exceed the configured max_login_attempts threshold (default: 50) before an IP block is applied. The vulnerability was published on April 29, 2026, and patched in version 4.14.4. It carries a CVSS v3.1 base score of 6.5 (Medium) (Wazuh Advisory).

The root cause is a combination of CWE-307 (Improper Restriction of Excessive Authentication Attempts), CWE-362 (Race Condition), and CWE-367 (TOCTOU Race Condition). The brute-force protection mechanism in api/api/middlewares.py uses module-level mutable state (ip_stats dict and ip_block set) that is not thread-safe, and the check-then-update logic in api/api/error_handler.py's prevent_bruteforce_attack function is non-atomic: it checks whether an IP is in ip_stats and then increments the attempt counter in separate, unsynchronized steps. When many requests arrive concurrently, all observe the "unblocked / attempts < limit" state before shared state is updated, allowing significantly more than the configured limit of failed attempts (e.g., 100 instead of 50) to be processed before the IP block is applied. A complete Python PoC using asyncio and aiohttp to demonstrate the bypass is included in the official advisory (Wazuh Advisory).

An unauthenticated attacker with network access to the Wazuh API can perform significantly more password guessing attempts than the configured brute-force protection policy intends, effectively undermining the account lockout control. This increases the likelihood of successfully guessing valid credentials for Wazuh API users, which could lead to unauthorized access to the Wazuh security management platform — including access to security alerts, agent configurations, and threat detection data. The confidentiality and integrity impacts are rated as low, with no direct availability impact (Wazuh Advisory).

A proof-of-concept Python script is publicly available in the official Wazuh security advisory, demonstrating the bypass using asyncio and aiohttp to send concurrent POST requests to the authentication endpoint. The exploit requires no authentication and no special privileges, making it accessible to any attacker with network access to the API. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.046% (Wazuh Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible Wazuh manager instances running versions 4.0.0–4.14.3, typically exposing the REST API on port 55000 (HTTPS).
2. Enumerate a valid username: Confirm a valid username exists (e.g., the default admin account). No valid password is required for the PoC.
3. Prepare the concurrent burst: Use the published Python PoC script (leveraging asyncio and aiohttp) configured with a burst size exceeding the max_login_attempts threshold (default 50), e.g., --burst 100.
4. Send concurrent authentication requests: Execute the script to fire all requests simultaneously to POST /security/user/authenticate with Basic Auth using the target username and incorrect passwords. Due to the TOCTOU race condition, most requests return HTTP 401 (counted as failed attempts) rather than HTTP 403 (blocked), allowing more guesses than the policy permits.
5. Verify bypass: After the burst, send a single additional request — it should return 403, confirming the IP is now blocked but that the burst window allowed excess attempts.
6. Repeat with valid password candidates: Iterate with different password guesses across burst windows (resetting between block periods) to conduct an accelerated brute-force or credential stuffing attack against the API (Wazuh Advisory).

• Network: High volume of concurrent HTTPS POST requests to port 55000 at /security/user/authenticate from a single source IP within a very short time window; requests arriving in tight parallel bursts rather than sequential patterns.
• Logs: Elevated count of POST /security/user/authenticate: 401 entries in /var/ossec/logs/api.log from a single IP, significantly exceeding the configured max_login_attempts value before a single 403 appears; presence of IP blocked due to exceeded number of logins attempts log entries following a burst.
• Logs (Docker): Output of grep -c 'POST /security/user/authenticate.*: 401' /var/ossec/logs/api.log showing counts far above the configured threshold in a short interval (Wazuh Advisory).

Upgrade Wazuh to version 4.14.4 or later, which includes a fix for the API login race condition (Fixed API login race condition - #34459) (Wazuh Release). For systems that cannot be patched immediately, consider implementing network-level rate limiting (e.g., via a WAF or firewall rule) on the Wazuh API port (default 55000) to restrict the rate of concurrent authentication requests from a single IP. Additionally, reducing the max_login_attempts value in /var/ossec/api/configuration/api.yaml can limit the window of exposure, though it does not eliminate the race condition (Wazuh Advisory).

The vulnerability was reported by researcher alimezar and published by Wazuh maintainer vikman90 on April 28, 2026. The advisory was referenced in the CISA vulnerability bulletin for the week of April 27, 2026. No significant broader media coverage or notable community debate has been identified beyond standard vulnerability tracking and aggregation sites.