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

CVE-2026-93346 is a race condition vulnerability in Wazuh's API login throttling mechanism that allows unauthenticated attackers to bypass the max_login_attempts brute-force protection by sending concurrent login requests. It affects Wazuh wazuh-manager versions 4.0.0 through 4.14.7, and was disclosed on October 13, 2026. The vulnerability is classified as an incomplete fix for a prior advisory (GHSA-m2mr-xhhv-jx58). It carries a CVSS v3.1 base score of 5.3 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Feedly).

The root cause is a time-of-check/time-of-use (TOCTOU) race condition (CWE-367) combined with improper restriction of excessive authentication attempts (CWE-307) and a concurrent execution race condition (CWE-362). The CheckBlockedIP middleware checks whether a source IP is blocked at the start of each request (check_blocked_ip), while the failure counter is only incremented after credential validation fails (prevent_bruteforce_attack in the error handler). Because credential validation is asynchronous and yields the event loop, a burst of concurrent requests all pass the block check before any failure is recorded — meaning the max_login_attempts threshold (default: 50) is never enforced against concurrent attempts. A secondary weakness compounds the issue: the block timestamp is set on the first failed attempt and never refreshed, so the lockout expires block_time seconds after the first attempt rather than the last, silently lifting the block during ongoing abuse. A prior fix (GHSA-m2mr-xhhv-jx58) introduced an asyncio.Lock to serialize counter updates, but this only orders bookkeeping and does not close the gate-to-count race (GitHub Advisory).

Successful exploitation allows an unauthenticated remote attacker to perform unlimited online password guessing against any Wazuh API account, including privileged accounts such as wazuh-wui and administrator accounts. The brute-force protection is completely defeated for concurrent request bursts — PoC testing demonstrated 100/100 attempts reaching credential validation regardless of the configured limit. Chained with weak, default, or reused credentials, this can lead to full account takeover of the Wazuh management plane, potentially granting an attacker control over the security monitoring infrastructure and all monitored endpoints (GitHub Advisory).

A proof-of-concept (PoC) was included in the advisory disclosure, consisting of both a local simulation script (poc3_bruteforce_race_sim.py) and a live-target script (poc3_bruteforce_live.py) that fire concurrent wrong-password login bursts to the /security/user/authenticate and /security/user/authenticate/run_as endpoints. The bypass is described as reliable rather than timing-fragile — even a single event-loop yield is sufficient to trigger it. No credentials, privileges, or user interaction are required. No in-the-wild exploitation has been reported, and the EPSS score is 0.0 at time of publication. The vulnerability is not currently listed in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing Wazuh manager instances running versions 4.0.0–4.14.7 using network scanning tools (e.g., Shodan, Censys) or by probing the API endpoint (default port 55000).
2. Identify target accounts: Enumerate or guess valid usernames (e.g., default accounts such as wazuh, wazuh-wui) by observing differences in API responses.
3. Prepare concurrent burst: Using an async HTTP client (e.g., Python asyncio + aiohttp), prepare a batch of N concurrent POST requests to /security/user/authenticate or /security/user/authenticate/run_as, each with a different password guess for the target account.
4. Fire concurrent requests: Launch all N requests simultaneously so they all pass the CheckBlockedIP gate check before any failure is recorded. Each request reaches credential validation (returning HTTP 401) rather than being blocked (HTTP 403), effectively bypassing max_login_attempts.
5. Repeat per window: Since the block timestamp is never refreshed, the lockout (if eventually triggered) expires block_time seconds after the first attempt. Repeat bursts after each window to continue guessing without restriction.
6. Achieve account takeover: Upon a successful credential match (HTTP 200 with JWT token), use the obtained token to authenticate to the Wazuh API and perform privileged management operations (GitHub Advisory).

• Network: High volume of concurrent HTTP POST requests to /security/user/authenticate or /security/user/authenticate/run_as from a single source IP within a short time window; responses predominantly HTTP 401 (rather than 403) despite exceeding max_login_attempts.
• Logs: Wazuh API access logs showing a large number of failed authentication attempts (401 responses) from the same IP without corresponding 403 block responses; absence of block enforcement entries despite repeated failures.
• Process/Behavior: Sudden successful authentication (HTTP 200) from an IP that previously generated many 401 errors, particularly for privileged accounts (wazuh, wazuh-wui); unexpected API activity following a burst of failed logins (GitHub Advisory).

Upgrade wazuh-manager to version 4.14.8 or later, which includes a fix for the API login attempt limit not being applied consistently under concurrent requests (PR #38135). The fix addresses the TOCTOU race by ensuring attempt counting occurs atomically before credential validation. No official configuration-based workaround is provided; as an interim measure, operators should restrict network access to the Wazuh API (port 55000) to trusted IP ranges and enforce strong, unique passwords for all API accounts (GitHub Advisory, Wazuh v4.14.8 Release).

The advisory was published by Wazuh on GitHub on October 13, 2026, crediting researcher iabdullah215 as the finder, vikman90 as the remediation developer, and sair-manzur as the reporter. The advisory explicitly frames this as an incomplete fix of a prior vulnerability (GHSA-m2mr-xhhv-jx58), highlighting the challenge of correctly fixing race conditions in async Python frameworks. No significant broader media coverage or social media discussion has been identified at time of reporting (GitHub Advisory).