CVE-2026-26206
Received Received - Intake
Brute Force Protection Bypass in Wazuh Server API

Publication date: 2026-04-29

Last updated on: 2026-04-30

Assigner: GitHub, Inc.

Description
Wazuh is a free and open source platform used for threat prevention, detection, and response. From version 4.0.0 to before version 4.14.4, Wazuh's server API brute-force protection for POST /security/user/authenticate can be bypassed by sending concurrent authentication requests. Although the configured threshold (max_login_attempts, default 50) is enforced correctly for sequential requests, a parallel burst allows significantly more failed login attempts to be processed before the IP block is applied. This enables an attacker to perform more password guesses than the configured policy intends (e.g., 100 attempts processed where 50 should be allowed). This issue has been patched in version 4.14.4.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-29
Last Modified
2026-04-30
Generated
2026-05-07
AI Q&A
2026-04-29
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
wazuh wazuh From 4.0.0 (inc) to 4.14.4 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-307 The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
CWE-367 The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability affects Wazuh server API versions from 4.0.0 to before 4.14.4. It allows an attacker to bypass the brute-force protection on the POST /security/user/authenticate endpoint by sending multiple concurrent authentication requests.

While the system correctly enforces a maximum number of failed login attempts (default 50) for sequential requests, it does not properly handle parallel bursts of requests. This means an attacker can make significantly more failed login attempts than intended before the IP address is blocked.

For example, instead of being limited to 50 failed attempts, an attacker could potentially make 100 failed attempts in parallel, increasing the chance of guessing passwords.

This issue was fixed in version 4.14.4 of Wazuh.


How can this vulnerability impact me? :

This vulnerability can increase the risk of unauthorized access to your Wazuh server by allowing attackers to perform more password guessing attempts than intended.

By bypassing the brute-force protection, attackers have a higher chance of successfully guessing user credentials, which could lead to compromised accounts.

Compromised accounts could allow attackers to gain access to sensitive threat detection and response data, potentially undermining your security posture.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, you should upgrade Wazuh to version 4.14.4 or later, where the issue has been patched.


Can you explain this vulnerability to me?

The CVE-2026-26206 vulnerability affects Wazuh versions 4.0.0 to before 4.14.4 and involves a flaw in the server API's brute-force protection mechanism for the POST /security/user/authenticate endpoint.

The issue arises because the brute-force protection logic does not properly handle concurrent authentication requests. While the system correctly limits failed login attempts when requests are sequential, sending multiple requests in parallel allows an attacker to bypass the configured threshold (default 50 attempts) and perform significantly more password guesses before the IP is blocked.

This happens due to a race condition where multiple concurrent requests see the IP as unblocked before the shared state is updated, allowing all these requests to be processed as failed attempts (returning 401) instead of being blocked (returning 403). The IP block is only applied after the burst of requests completes.

The root cause is non-atomic check-then-update logic in the brute-force protection function, which relies on mutable shared state without proper synchronization.

This vulnerability was fixed in Wazuh version 4.14.4.


How can this vulnerability impact me? :

This vulnerability allows an attacker to bypass the intended brute-force protection limits on login attempts, enabling them to perform more password guesses than the configured policy allows.

As a result, an attacker can increase the chances of successfully guessing user passwords, potentially leading to unauthorized access to user accounts.

The impact includes a low but real risk to confidentiality and integrity of the system, as unauthorized access could expose sensitive information or allow malicious actions under compromised accounts.

The vulnerability has a CVSS v3 base score of 6.5, indicating medium severity, with no impact on system availability.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring the authentication requests to the POST /security/user/authenticate endpoint on the Wazuh server API. Specifically, detection involves identifying bursts of concurrent failed login attempts that exceed the configured max_login_attempts threshold without triggering immediate IP blocking.

A proof-of-concept shows that sending a high number of concurrent authentication requests (e.g., 100) results in many 401 Unauthorized responses without 403 Forbidden responses during the burst, indicating the brute-force protection bypass.

To detect this on your system, you can analyze your web server or Wazuh API logs for patterns of multiple simultaneous 401 responses from the same IP address without immediate 403 blocking.

Suggested commands might include using tools like curl or custom scripts to simulate concurrent POST requests to the /security/user/authenticate endpoint and monitoring the HTTP response codes.

  • Use curl in a loop or parallel execution to send multiple concurrent POST requests to the authentication endpoint.
  • Check logs for repeated 401 responses from the same IP without corresponding 403 responses during the burst.
  • Example command to simulate concurrent requests (using GNU parallel):

parallel -j 100 curl -X POST https://<wazuh-server>/security/user/authenticate -d '{"user":"invalid","password":"invalid"}' ::: {1..100}


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation step is to upgrade Wazuh to version 4.14.4 or later, where this vulnerability has been fixed.

Version 4.14.4 addresses the race condition in the API login brute-force protection mechanism, ensuring proper synchronization and enforcement of the max_login_attempts threshold even under concurrent requests.

Until the upgrade can be applied, consider implementing additional network-level protections such as rate limiting or firewall rules to restrict the number of concurrent authentication attempts from the same IP address.

Monitoring and alerting on unusual bursts of failed login attempts can also help in early detection and response.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability allows an attacker to bypass brute-force protection on the Wazuh server API, enabling more password guesses than intended by the security policy. This could potentially increase the risk of unauthorized access to sensitive systems or data.

While the CVE description and resources do not explicitly mention compliance with standards such as GDPR or HIPAA, the increased risk of unauthorized access due to this vulnerability could impact an organization's ability to maintain compliance with regulations that require strong access controls and protection of sensitive data.

Organizations relying on Wazuh for threat prevention and detection should ensure they update to version 4.14.4 or later to mitigate this issue and maintain compliance with security best practices.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart