CVE-2026-26206: Wazuh Auth Bypass Vulnerability

CVE-2026-26206 Overview

CVE-2026-26206 is an authentication bypass vulnerability in Wazuh, a free and open source platform used for threat prevention, detection, and response. The vulnerability affects Wazuh versions from 4.0.0 to before 4.14.4 and allows attackers to bypass the server API's brute-force protection mechanism by sending concurrent authentication requests to the POST /security/user/authenticate endpoint.

While the configured threshold (max_login_attempts, default 50) is correctly enforced for sequential requests, a parallel burst of authentication attempts allows significantly more failed login attempts to be processed before the IP block is applied. This race condition enables an attacker to perform more password guesses than the configured policy intends—for example, processing 100 attempts when only 50 should be allowed.

Critical Impact

Attackers can bypass brute-force protection controls to conduct credential stuffing and password guessing attacks against Wazuh server API authentication, potentially gaining unauthorized access to security management infrastructure.

Affected Products

• Wazuh versions 4.0.0 to 4.14.3
• Wazuh Server API authentication endpoint
• Systems relying on max_login_attempts configuration for brute-force protection

Discovery Timeline

• 2026-04-29 - CVE CVE-2026-26206 published to NVD
• 2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-26206

Vulnerability Analysis

This vulnerability is classified under CWE-307 (Improper Restriction of Excessive Authentication Attempts). The core issue lies in how Wazuh's API server processes concurrent authentication requests. The brute-force protection mechanism was designed to track failed login attempts and block IP addresses after exceeding the max_login_attempts threshold. However, the implementation fails to properly handle race conditions when multiple authentication requests arrive simultaneously.

When an attacker sends a burst of parallel HTTP POST requests to the /security/user/authenticate endpoint, each request is processed in its own thread or connection context. The authentication failure counter increments for each failed attempt, but the IP blocking logic only triggers after the counter check completes. In a parallel attack scenario, multiple requests can pass the threshold check before any single request triggers the block, allowing substantially more authentication attempts than intended.

Root Cause

The root cause is a race condition in the authentication rate-limiting implementation. The check-then-act pattern used to verify the number of failed attempts and apply IP blocking is not atomic. When concurrent requests are processed, multiple threads can simultaneously read the current failure count, determine it is below the threshold, and proceed with authentication attempts before any single thread increments the counter and triggers the blocking mechanism.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability remotely by:

1. Targeting the Wazuh Server API authentication endpoint (POST /security/user/authenticate)
2. Sending a large burst of concurrent HTTP requests with different password guesses
3. Timing the attack to ensure requests are processed in parallel before the IP block takes effect
4. Repeating the burst attack after the blocking period expires to continue password enumeration

The attack effectively multiplies the number of allowed password guesses, significantly reducing the time required for successful credential compromise through brute-force methods.

Detection Methods for CVE-2026-26206

Indicators of Compromise

• Unusual spikes in authentication requests to /security/user/authenticate endpoint in short time windows
• Multiple concurrent connections from single IP addresses attempting authentication
• Log entries showing authentication failures exceeding the configured max_login_attempts threshold
• Network traffic patterns indicating HTTP request parallelization tools (e.g., multiple simultaneous TCP connections)

Detection Strategies

• Monitor Wazuh API access logs for burst patterns of authentication attempts from individual IP addresses
• Implement network-level rate limiting or Web Application Firewall (WAF) rules to detect and block rapid authentication request bursts
• Configure alerting on authentication failure rates that exceed expected baseline patterns
• Deploy behavioral analysis to identify credential stuffing attack signatures

Monitoring Recommendations

• Enable detailed logging for the Wazuh Server API authentication endpoint
• Set up real-time alerting for authentication anomalies using SIEM integration
• Monitor network flow data for unusual connection patterns to Wazuh API ports
• Review blocked IP logs to identify potential attack campaigns that partially succeeded

How to Mitigate CVE-2026-26206

Immediate Actions Required

• Upgrade Wazuh to version 4.14.4 or later immediately
• Implement network-level rate limiting at load balancers or reverse proxies as a defense-in-depth measure
• Reduce max_login_attempts threshold to minimize the impact of any bypass
• Enable IP allowlisting for API access where operationally feasible

Patch Information

Wazuh has released version 4.14.4 which addresses this vulnerability by implementing proper synchronization in the brute-force protection mechanism. The patch ensures that concurrent authentication requests are properly counted and blocked according to the configured threshold.

For detailed patch information, refer to the GitHub Wazuh Release v4.14.4 and the GitHub Security Advisory GHSA-m2mr-xhhv-jx58.

Workarounds

• Deploy a reverse proxy with connection rate limiting in front of the Wazuh API to enforce request throttling before traffic reaches the application
• Configure network firewall rules to limit concurrent connections per source IP to the Wazuh API port
• Implement multi-factor authentication (MFA) for Wazuh API access to reduce the impact of credential compromise
• Use VPN or IP allowlisting to restrict API access to trusted network ranges only

# Example: Configure nginx rate limiting as a reverse proxy workaround
# Add to nginx configuration for Wazuh API proxy
limit_req_zone $binary_remote_addr zone=wazuh_auth:10m rate=5r/s;

location /security/user/authenticate {
    limit_req zone=wazuh_auth burst=10 nodelay;
    proxy_pass https://wazuh-api-backend;
}