CVE-2026-25771: 
Wazuh Agent vulnerability analysis and mitigation

CVE-2026-25771 is a Denial of Service (DoS) vulnerability in the Wazuh API authentication middleware (middlewares.py) caused by synchronous blocking I/O within an asynchronous event loop. It affects Wazuh versions 4.3.0 through 4.14.2 (inclusive), and was disclosed on March 17, 2026, with a fix released in version 4.14.3. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) per NVD, though the GitHub advisory rates it as Moderate (5.3) (GitHub Advisory, Red Hat CVE).

The root cause (CWE-400: Uncontrolled Resource Consumption) lies in the access_log function within api/middlewares.py, which calls the synchronous generate_keypair() function from api/authentication.py on every HTTP request that includes a Bearer token. generate_keypair() uses blocking Python open() and read() calls to load private_key.pem and public_key.pem from disk, halting the entire Starlette/Asyncio single-threaded event loop during each file read. Because this occurs on every Bearer token request — including those with invalid tokens from unauthenticated users — an attacker can flood the API with high-concurrency requests to repeatedly stall the event loop, starving the application of CPU resources. A complete, runnable PoC (wazuh_dos_poc.py) is included in the official advisory, using aiohttp with 2,000 concurrent workers sending junk Bearer tokens (GitHub Advisory).

Successful exploitation causes the Wazuh API process to spike to 100% CPU usage on a single core, preventing it from accepting or processing legitimate connections and effectively rendering the security monitoring platform's API unavailable. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. Because Wazuh is a security operations platform used for threat detection and response, API unavailability could impair security monitoring, alerting, and incident response workflows for affected organizations (GitHub Advisory, Red Hat CVE).

1. Reconnaissance: Identify internet-facing Wazuh Manager instances running versions 4.3.0–4.14.2 by scanning for the default Wazuh API port (TCP 55000) using tools like Shodan, Censys, or Nmap.
2. Prepare the PoC script: Obtain or replicate the wazuh_dos_poc.py script from the public advisory. Set TARGET_URL to the target Wazuh API endpoint (e.g., https://<target-ip>:55000/) and configure CONCURRENCY to a high value (e.g., 2000 workers).
3. Generate junk Bearer tokens: The script automatically generates random 50-character strings as Bearer tokens in the Authorization header, which are sufficient to trigger the access_log → generate_keypair() code path without requiring valid credentials.
4. Launch the flood: Execute the script (python3 wazuh_dos_poc.py). Each concurrent worker continuously sends GET requests with junk Bearer tokens and short timeouts (2 seconds) to maximize request throughput and keep the server saturated.
5. Event loop starvation: Each incoming request causes the Wazuh API's async event loop to call generate_keypair(), which blocks on disk I/O to read private_key.pem and public_key.pem. Under high concurrency, these blocking calls accumulate and consume 100% of the single-threaded event loop's CPU time.
6. Denial of Service achieved: The Wazuh API becomes unresponsive to legitimate requests, timing out or refusing connections. Verification can be performed by running htop on the server to observe CPU saturation, or strace to confirm repeated open() calls to the PEM key files (GitHub Advisory).

• Network: High volume of HTTP GET/POST requests to the Wazuh API port (TCP 55000) from one or multiple source IPs, each containing an Authorization: Bearer <random_string> header with invalid or malformed tokens; short-duration connections with rapid reconnection patterns consistent with aiohttp fire-and-forget behavior.
• Process: Wazuh API process (wazuh-apid) exhibiting sustained 100% CPU usage on a single core as observed via htop or top; API process becoming unresponsive to legitimate management requests.
• Logs: Wazuh API access logs showing a flood of requests with Bearer tokens that fail JWT validation; repeated log entries from middlewares.py indicating token decode failures at high frequency.
• File System / OS: Output of strace -p <wazuh-api-pid> -e trace=open,read showing an endless stream of open() calls to private_key.pem and public_key.pem in the Wazuh API key directory (GitHub Advisory).

The primary remediation is to upgrade Wazuh to version 4.14.3 or later, which resolves the issue by caching the key file contents in memory (e.g., using functools.lru_cache) so that generate_keypair() no longer performs blocking disk I/O on every request (GitHub Advisory). For environments unable to patch immediately, the following mitigations can reduce exposure:

• Implement rate limiting on the Wazuh API (port 55000) at the network or reverse proxy level to restrict the number of requests per source IP.
• Use firewall rules or network access controls to restrict API access to trusted IP ranges only, preventing unauthenticated external access.
• Deploy a WAF or API gateway in front of the Wazuh API to detect and block request floods with invalid Bearer tokens.

The vulnerability was reported by security researcher skraft9 and published by Wazuh maintainer vikman90 via the GitHub Security Advisory program on March 17, 2026 (GitHub Advisory). Red Hat also tracked the vulnerability in their CVE database (Red Hat CVE). No significant broader media coverage or notable social media commentary has been identified beyond standard CVE aggregator publications.