Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LSummary
CVE-2026-25771 is a medium-severity Uncontrolled Resource Consumption (CWE-400) vulnerability in Wazuh Wazuh. Its CVSS base score is 5.3 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique OS Exhaustion Flood (T1499.001); ranked at the 38th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SC-5 (Denial-of-service Protection) and SC-6 (Resource Availability) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-25771 is a Denial of Service (DoS) vulnerability in the Wazuh API authentication middleware, located in middlewares.py. Wazuh, a free and open source platform for threat prevention, detection, and response, is affected in versions starting from 4.3.0 and prior to 4.14.3. The issue stems from the application's use of an asynchronous event loop (Starlette/Asyncio) that invokes a synchronous function, generate_keypair, which performs blocking disk I/O on every request containing a Bearer token. This design flaw leads to resource exhaustion under load.
An unauthenticated remote attacker can exploit this vulnerability by flooding the Wazuh API with requests containing invalid Bearer tokens. Each such request triggers the blocking disk I/O operation, causing the single-threaded event loop to pause repeatedly. This starves the application of CPU resources, potentially preventing it from accepting or processing legitimate connections and resulting in a DoS condition. The vulnerability has a CVSS v3.1 base score of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) and is associated with CWE-400 (Uncontrolled Resource Consumption).
The Wazuh security advisory at https://github.com/wazuh/wazuh/security/advisories/GHSA-33w3-p5hm-jw7g details the issue and confirms that version 4.14.3 addresses the vulnerability by fixing the blocking behavior in the authentication middleware. Security practitioners should upgrade to Wazuh 4.14.3 or later to mitigate the risk.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-12620
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
SC-5 directly limits the effects of resource-exhaustion events that constitute uncontrolled consumption.
SC-6 enforces explicit allocation limits on resources, structurally preventing the weakness from occurring.
Process isolation confines resource consumption to separate domains, reducing blast radius without stopping the root flaw.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Explicitly requires monitoring and maintaining resource capacity, directly addressing uncontrolled consumption to preserve availability.
Continuous monitoring of computing resources can detect resource exhaustion but does not itself enforce allocation limits.
Resilience mechanisms such as avoiding single points of failure indirectly reduce impact of resource exhaustion.
Hardened configuration baselines can include resource quotas and limits that constrain consumption.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Resource-utilization monitoring and alerting on bottlenecks or overloads limits the impact of denial-of-service or resource-exhaustion attacks.
By continuously monitoring utilization, stress-testing peak loads, and maintaining documented plans to scale or throttle resources, the control directly limits an attacker’s ability to drive a system into uncontrolled resource exhaustion.
Pre-agreed severity-based prioritization and resource allocation during incident triage reduce the likelihood that an attacker-induced resource exhaustion will overwhelm the organization before corrective action is taken.
Business-continuity plans that include resource-management controls reduce the likelihood that an attacker can trigger uncontrolled resource consumption by forcing the system into a degraded or fallback state.
Defining RTOs and capacity requirements for ICT services during business-impact analysis forces organizations to provision sufficient resources and throttling mechanisms, reducing the likelihood that an attacker can induce denial-of-service through uncontrolled resource consumption.
Early notification of anomalous resource consumption or system malfunctions enables throttling or isolation before availability is lost.