CVE-2026-25771: Wazuh API DoS Vulnerability

CVE-2026-25771 Overview

CVE-2026-25771 is a Denial of Service (DoS) vulnerability in the Wazuh API authentication middleware (middlewares.py). Wazuh is a free and open source platform for threat prevention, detection, and response. The flaw affects versions 4.3.0 through 4.14.2 and stems from a synchronous blocking disk I/O call invoked from within an asynchronous event loop. An unauthenticated remote attacker can flood the API with requests containing invalid Bearer tokens to starve the single-threaded event loop of CPU resources. Wazuh resolved the issue in version 4.14.3.

Critical Impact

Unauthenticated remote attackers can exhaust Wazuh API CPU resources, preventing legitimate connections to a core security monitoring platform.

Affected Products

• Wazuh versions 4.3.0 through 4.14.2
• Wazuh API authentication middleware (middlewares.py)
• Wazuh manager components exposing the API endpoint

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

The vulnerability resides in the Wazuh API authentication middleware implemented in middlewares.py. Wazuh runs its API on an asynchronous Starlette/Asyncio event loop. The middleware invokes a synchronous function, generate_keypair, on every incoming request that contains a Bearer token. This function performs blocking disk I/O operations to read key material from the filesystem.

Because the event loop is single-threaded, every blocking call pauses the entire loop until the disk read completes. An attacker who sends a high volume of requests with arbitrary invalid Bearer tokens forces repeated blocking I/O. Legitimate requests cannot be accepted or processed while the loop is stalled. The weakness is categorized as Uncontrolled Resource Consumption [CWE-400].

Root Cause

The root cause is the misuse of a synchronous, I/O-bound function inside an asynchronous request handler. Asyncio applications must offload blocking I/O to a thread pool or use async file operations. The generate_keypair call also executes on every Bearer-token request rather than being cached or scoped to authenticated sessions, amplifying the impact.

Attack Vector

The attack requires no authentication and no user interaction. An attacker reachable over the network sends concurrent HTTP requests to the Wazuh API with a Bearer authorization header containing any token value. Each request triggers the blocking keypair read regardless of validity. Sustained request volume effectively halts API responsiveness and disrupts agent management, alerting, and integrations that depend on the Wazuh API.

No verified public proof-of-concept code is available. See the Wazuh GitHub Security Advisory for vendor technical details.

Detection Methods for CVE-2026-25771

Indicators of Compromise

• High volume of HTTP requests to the Wazuh API containing Authorization: Bearer headers with invalid or malformed tokens.
• Sustained spikes in CPU utilization on the Wazuh API process correlated with elevated 401 Unauthorized responses.
• API request latency increases and timeouts reported by Wazuh agents or integrated SIEM connectors.

Detection Strategies

• Monitor Wazuh API access logs for repeated authentication failures originating from a small set of source IPs or user agents.
• Alert on anomalous request rates against the API listener port (default 55000) outside expected operational baselines.
• Correlate Wazuh manager process performance metrics with API request volume to identify event loop stalls.

Monitoring Recommendations

• Forward Wazuh API logs and host telemetry to a centralized analytics platform for rate and pattern analysis.
• Track the ratio of failed-to-successful API authentications and trigger alerts on sudden deviations.
• Instrument network-layer counters at the reverse proxy or load balancer fronting the Wazuh API to detect flooding patterns early.

How to Mitigate CVE-2026-25771

Immediate Actions Required

• Upgrade all Wazuh manager instances to version 4.14.3 or later, which removes the blocking I/O from the authentication path.
• Restrict network access to the Wazuh API to trusted management subnets using firewall rules or security groups.
• Place the Wazuh API behind a reverse proxy that enforces rate limiting and connection throttling.

Patch Information

Wazuh version 4.14.3 fixes CVE-2026-25771. Review the vendor advisory at GHSA-33w3-p5hm-jw7g for upgrade guidance and release notes. Apply the upgrade across all Wazuh manager nodes in clustered deployments to ensure consistent protection.

Workarounds

• Apply strict per-source-IP rate limits at an upstream proxy to constrain Bearer token request volume.
• Enforce mutual TLS or IP allowlists on the Wazuh API so unauthenticated external traffic cannot reach the authentication middleware.
• Monitor and automatically block source addresses that generate sustained authentication failures against the API.

# Configuration example: rate limit Wazuh API at an nginx reverse proxy
http {
    limit_req_zone $binary_remote_addr zone=wazuh_api:10m rate=10r/s;

    server {
        listen 443 ssl;
        server_name wazuh.example.local;

        location / {
            limit_req zone=wazuh_api burst=20 nodelay;
            allow 10.0.0.0/24;
            deny all;
            proxy_pass https://127.0.0.1:55000;
        }
    }
}