CVE-2026-25771
Received Received - Intake
Denial of Service in Wazuh API Authentication Middleware

Publication date: 2026-03-17

Last updated on: 2026-03-19

Assigner: GitHub, Inc.

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-17
Last Modified
2026-03-19
Generated
2026-05-07
AI Q&A
2026-03-17
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
wazuh wazuh From 4.3.0 (inc) to 4.14.3 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-400 The product does not properly control the allocation and maintenance of a limited resource.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-25771 is a Denial of Service (DoS) vulnerability in the Wazuh API authentication middleware affecting versions from 4.3.0 up to but not including 4.14.3.

The issue occurs because the Wazuh API uses an asynchronous event loop but calls a synchronous function, generate_keypair(), on every request containing a Bearer token. This function performs blocking disk I/O by reading key files synchronously.

An unauthenticated remote attacker can exploit this by flooding the API with requests containing invalid Bearer tokens, causing the single-threaded event loop to block repeatedly on file reads. This leads to high CPU usage on one core, starving the application of resources and potentially preventing it from processing legitimate requests.

The vulnerability is fixed in version 4.14.3 by caching the key files in memory to avoid repeated blocking disk access.


How can this vulnerability impact me? :

[{'type': 'paragraph', 'content': 'This vulnerability can cause a Denial of Service condition on the Wazuh API server.'}, {'type': 'paragraph', 'content': "By exploiting this flaw, an attacker can flood the API with invalid Bearer token requests, causing the server's single-threaded event loop to block on synchronous disk I/O operations."}, {'type': 'paragraph', 'content': 'As a result, the API process may consume 100% CPU on a single core, hang, and become unresponsive, preventing legitimate users and applications from accessing or using the API.'}] [1]


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

I don't know


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

This vulnerability can be detected by monitoring the Wazuh API process for unusually high CPU usage on a single core, which indicates the event loop is being blocked.

Using system monitoring tools like `htop` can reveal the API process consuming 100% CPU on one core.

Additionally, using `strace` on the Wazuh API process can show continuous `open()` system calls to the `public_key.pem` file, indicating repeated blocking disk I/O.

  • Run `htop` and look for the Wazuh API process consuming 100% CPU on a single core.
  • Use `strace -p <pid_of_wazuh_api>` to trace system calls and check for repeated `open()` calls to `public_key.pem`.

What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation is to upgrade the Wazuh platform to version 4.14.3 or later, where this vulnerability is fixed.

The fix involves caching the key files in memory after the first read to avoid repeated blocking disk I/O operations in the asynchronous event loop.

Until the upgrade is applied, consider limiting or blocking excessive requests containing Bearer tokens from unauthenticated sources to reduce the risk of DoS.


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