CVE-2026-25771 in Wazuh
Summary
by MITRE • 03/17/2026
Wazuh is a free and open source platform used for threat prevention, detection, and response. Starting in version 4.3.0 and prior to version 4.14.3, a Denial of Service (DoS) vulnerability exists in the Wazuh API authentication middleware (`middlewares.py`). The application uses an asynchronous event loop (Starlette/Asyncio) to call a synchronous function (`generate_keypair`) that performs blocking disk I/O on every request containing a Bearer token. An unauthenticated remote attacker can exploit this by flooding the API with requests containing invalid Bearer tokens. This forces the single-threaded event loop to pause for file read operations repeatedly, starving the application of CPU resources and potentially preventing it from accepting or processing legitimate connections. Version 4.14.3 fixes the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/21/2026
The vulnerability described in CVE-2026-25771 represents a critical denial of service weakness within the Wazuh security platform that affects versions between 4.3.0 and 4.14.2 inclusive. This issue resides within the application's authentication middleware component specifically in the middlewares.py file where the system employs an asynchronous event loop architecture built on Starlette and Asyncio frameworks. The fundamental flaw occurs when the system processes requests containing Bearer tokens by invoking a synchronous function called generate_keypair which performs blocking disk input/output operations. This architectural mismatch between asynchronous request handling and synchronous blocking operations creates a significant performance bottleneck that can be exploited by malicious actors.
The technical implementation of this vulnerability stems from improper handling of concurrent execution patterns within the Wazuh API framework. When an attacker submits multiple requests with invalid Bearer tokens, each request triggers the synchronous generate_keypair function that performs file read operations on the disk. Since these operations are blocking in nature, they prevent the single-threaded event loop from processing other incoming requests effectively. The asynchronous nature of the Starlette framework expects non-blocking operations to maintain optimal throughput, but the synchronous disk I/O operations cause the event loop to stall repeatedly. This creates a resource starvation condition where legitimate requests cannot be processed due to the CPU being consumed by the blocking operations, effectively rendering the API unresponsive to both malicious and legitimate traffic.
The operational impact of this vulnerability extends beyond simple service disruption to potentially compromise the entire security monitoring infrastructure that Wazuh provides. An unauthenticated remote attacker can exploit this weakness by flooding the API with invalid Bearer token requests, causing the system to consume excessive CPU resources and potentially leading to complete service unavailability. This type of attack aligns with attack patterns documented in the MITRE ATT&CK framework under the denial of service category, specifically targeting application availability through resource exhaustion. The vulnerability also relates to CWE-674, which describes uncontrolled resource consumption in software systems, and CWE-1135 which addresses improper handling of asynchronous operations in concurrent environments. Organizations relying on Wazuh for threat prevention, detection, and response capabilities face significant operational risk as this vulnerability can be exploited without authentication, potentially causing extended periods of service degradation or complete system outages.
The mitigation for this vulnerability requires immediate upgrading to Wazuh version 4.14.3 or later where the issue has been resolved through proper asynchronous handling of the key generation process. Security teams should implement network-level rate limiting and monitoring to detect unusual patterns of authentication requests that could indicate exploitation attempts. Additionally, organizations should review their deployment configurations to ensure that the API authentication middleware properly handles both valid and invalid token scenarios without causing resource starvation. The fix implemented in version 4.14.3 addresses the core architectural issue by ensuring that disk I/O operations are properly handled within the asynchronous execution model, preventing the single-threaded event loop from being blocked by synchronous operations. This remediation aligns with best practices for asynchronous programming in modern web frameworks and prevents the conditions that enable this denial of service attack vector.