CVE-2026-74039 in Manager
Summary
by MITRE • 08/18/2026
Wazuh 4.0.0 before 4.14.7 and 5.0.0-beta2 contain a denial of service vulnerability that allows authenticated attackers with allow_run_as enabled to exhaust CPU resources by submitting arbitrarily deeply nested JSON structures to the POST /security/user/authenticate/run_as endpoint. Attackers can repeatedly submit malformed auth_context bodies with unlimited nesting depth to cause the API framework to consume excessive CPU, denying service to all other API consumers.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Wazuh versions prior to 4.14.7 and version 5.0.0-beta2 represents a significant denial of service risk within the security management platform's authentication subsystem. This flaw specifically targets the POST /security/user/authenticate/run_as endpoint, which is designed to allow users with specific privileges to execute commands under different user identities. The core technical deficiency lies in the lack of depth validation for JSON structures submitted as part of the auth_context body during this run-as operation. When an authenticated attacker possesses the allow_run_as privilege, they can exploit this absence by crafting requests containing arbitrarily deeply nested JSON objects. This behavior triggers a recursive processing loop within the API framework's parser or handler logic, leading to unbounded resource consumption on the server side.
From a technical perspective, this vulnerability is classified under CWE-400, which denotes Uncontrolled Resource Consumption. The mechanism of exploitation relies on the application failing to enforce limits on recursion depth or JSON nesting levels before processing the payload. As the framework attempts to deserialize and validate these deeply nested structures, it consumes excessive CPU cycles attempting to traverse the complex data structure. This is not a memory exhaustion vulnerability in the traditional sense but rather a computational resource depletion attack. The attacker does need valid credentials with run-as permissions, which elevates this from an unauthenticated remote code execution or denial of service to an authenticated insider threat scenario or a compromise of privileged accounts.
The operational impact of this flaw is severe for environments relying on Wazuh for centralized security monitoring and incident response. By repeatedly submitting malformed auth_context bodies with unlimited nesting depth, an attacker can cause the API framework to consume excessive CPU resources. This sustained high CPU load effectively denies service to all other legitimate API consumers who rely on the platform for real-time log analysis, alert generation, and agent management. In a production environment, this could lead to delayed incident response times, missed security alerts, or complete unavailability of the Wazuh dashboard and API services, thereby undermining the organization's ability to detect and react to threats in real time.
This vulnerability aligns with MITRE ATT&CK technique T1496, Resource Hijacking, where attackers use compromised resources for their own purposes, such as causing denial of service or mining cryptocurrency, although here the intent is purely disruptive. It also relates to CWE-787, Out-of-bounds Write, if the underlying parser exhibits buffer handling issues due to deep recursion, though the primary manifestation described is CPU exhaustion. The attack vector involves network access with authentication requirements, placing it in a higher privilege context than typical unauthenticated DoS attacks but still posing a critical risk to service availability for privileged users.
Mitigation strategies must prioritize immediate patching of the Wazuh installation to version 4.14.7 or later, where this validation logic has been corrected. For environments unable to patch immediately due to operational constraints, network-level controls should be implemented to restrict access to the /security/user/authenticate/run_as endpoint only from trusted IP addresses and administrative networks. Additionally, implementing rate limiting on authentication endpoints can help mitigate the impact of repeated malicious requests. Security teams should also audit user accounts with allow_run_as privileges to ensure that such high-privilege capabilities are granted strictly according to the principle of least privilege, reducing the number of potential attack vectors available to compromised or insider threat actors. Regular monitoring for unusual spikes in CPU usage associated with API authentication processes can serve as an early detection mechanism for ongoing exploitation attempts.