CVE-2026-25771: Wazuh Platform DoS Vulnerability

CVE-2026-25771 Overview

A Denial of Service (DoS) vulnerability exists in the Wazuh API authentication middleware (middlewares.py). The Wazuh platform, an open source security solution for threat prevention, detection, and response, contains a flaw in how the API processes Bearer token authentication. 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, forcing 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.

Critical Impact

Unauthenticated attackers can remotely disrupt Wazuh security monitoring capabilities by exhausting API resources through a flood of invalid Bearer token requests, potentially leaving infrastructure unmonitored during critical security events.

Affected Products

• Wazuh versions 4.3.0 through 4.14.2
• Wazuh API authentication middleware (middlewares.py)
• Systems running Wazuh with exposed API endpoints

Discovery Timeline

• 2026-03-17 - CVE-2026-25771 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-25771

Vulnerability Analysis

This vulnerability represents a classic resource exhaustion condition (CWE-400) arising from improper handling of asynchronous and synchronous code patterns within the Wazuh API. The root issue lies in the architectural decision to invoke a blocking synchronous function within an asynchronous event loop context.

When the Wazuh API receives a request with a Bearer token, the authentication middleware calls the generate_keypair function to validate the token. This function performs blocking disk I/O operations to read cryptographic key material from the filesystem. In an asynchronous application built on Starlette/Asyncio, blocking operations within the event loop are particularly dangerous because they halt all concurrent request processing until the blocking operation completes.

The vulnerability requires no authentication to exploit, meaning any network-accessible attacker can initiate an attack. The attack does not compromise data confidentiality or integrity but can severely impact system availability by preventing legitimate security monitoring operations.

Root Cause

The root cause of CVE-2026-25771 is the invocation of the synchronous generate_keypair function from within the asynchronous event loop in middlewares.py. This function performs blocking file I/O operations to read key material from disk. In Python's asyncio model, blocking operations in the main event loop prevent all other coroutines from executing until the blocking call returns. This architectural flaw allows attackers to monopolize the event loop by triggering repeated blocking operations, effectively creating a resource starvation condition.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker exploits this vulnerability by sending a high volume of HTTP requests to the Wazuh API, each containing an arbitrary Bearer token in the Authorization header. The token does not need to be valid—any Bearer token value will trigger the vulnerable code path.

Each malicious request forces the API to:

1. Parse the Bearer token from the request headers
2. Call the synchronous generate_keypair function
3. Perform blocking disk I/O to read key files
4. Block all other request processing during file operations

By sustaining a flood of such requests, the attacker can effectively prevent the single-threaded event loop from processing any legitimate requests, resulting in a denial of service condition.

Detection Methods for CVE-2026-25771

Indicators of Compromise

• Unusually high volume of HTTP requests to Wazuh API endpoints with Bearer token authentication headers
• Elevated disk I/O activity on systems hosting the Wazuh API
• API response latency spikes or timeout errors for legitimate management operations
• High CPU utilization on Wazuh API processes without corresponding increase in legitimate traffic

Detection Strategies

• Monitor network traffic for sustained bursts of requests to Wazuh API endpoints, particularly those with Authorization headers
• Implement rate limiting detection at the network perimeter to identify sources generating excessive API requests
• Configure application performance monitoring (APM) to alert on event loop starvation or blocking operation patterns
• Review Wazuh API access logs for patterns of failed authentication attempts from single or distributed sources

Monitoring Recommendations

• Deploy SentinelOne Singularity to monitor for anomalous process behavior and resource utilization on Wazuh server infrastructure
• Establish baseline metrics for normal Wazuh API request rates and alert on significant deviations
• Configure network monitoring to detect potential DDoS patterns targeting Wazuh API endpoints
• Implement centralized logging for Wazuh API authentication events to enable rapid forensic analysis

How to Mitigate CVE-2026-25771

Immediate Actions Required

• Upgrade Wazuh to version 4.14.3 or later, which contains the fix for this vulnerability
• Review network access controls to limit exposure of Wazuh API endpoints to trusted networks only
• Implement rate limiting at reverse proxy or load balancer level to throttle excessive API requests
• Monitor Wazuh API performance metrics for signs of ongoing exploitation attempts

Patch Information

Wazuh has released version 4.14.3 which addresses this vulnerability. The fix modifies the authentication middleware to properly handle the key generation function in a non-blocking manner, preventing event loop starvation. Organizations should prioritize upgrading to this version, particularly for internet-exposed or critical security monitoring deployments. Detailed information about the fix is available in the GitHub Security Advisory.

Workarounds

• Place Wazuh API behind a reverse proxy with rate limiting capabilities to mitigate flood attacks
• Restrict API access to trusted IP addresses using firewall rules or network ACLs
• Implement a Web Application Firewall (WAF) with rules to detect and block rapid authentication attempt patterns
• Consider disabling external API access if not required for operational purposes until patching is complete

# Example: Rate limiting configuration for nginx reverse proxy
# Add to nginx server block protecting Wazuh API
limit_req_zone $binary_remote_addr zone=wazuh_api:10m rate=10r/s;
location /api/ {
    limit_req zone=wazuh_api burst=20 nodelay;
    proxy_pass http://wazuh-api-backend;
}