CVE-2026-74032 in Wazuh
Summary
by MITRE • 10/13/2026
Wazuh from 4.0.0 before 4.14.8 contains an authorization bypass vulnerability that allows low-privileged authenticated users to read the RBAC catalog by querying unprotected security endpoints. Attackers can request GET /security/actions and /security/resources, which omit the caller's RBAC policies, to map privileged actions and endpoints for privilege escalation planning.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/13/2026
The identified vulnerability in Wazuh versions ranging from 4.0.0 up to but not including 4.14.8 represents a critical authorization bypass flaw within the application’s security architecture. This issue stems from improper access control mechanisms on specific internal API endpoints, specifically those related to system configuration and policy management. The core technical failure lies in the server's handling of requests directed at GET /security/actions and GET /security/resources. These endpoints are designed to return metadata regarding available actions and resources within the Role-Based Access Control (RBAC) engine. However, due to a misconfiguration or logic error in the middleware layer, these endpoints fail to enforce authentication checks that validate whether the requesting user possesses sufficient privileges to view this sensitive structural information. Consequently, any authenticated user, regardless of their assigned role or permission level, can successfully query these endpoints and retrieve comprehensive details about the system's security policies.
From a technical perspective, the vulnerability exploits the lack of authorization validation on read-only metadata endpoints that expose the internal schema of the RBAC engine. In a properly secured implementation, such endpoints should either be restricted to administrative users or return empty responses for non-privileged accounts. By bypassing this check, an attacker can map out the entire landscape of privileged actions and protected resources defined within the Wazuh environment. This information disclosure is particularly dangerous because it provides attackers with a detailed blueprint of what they are attempting to access. Instead of guessing which endpoints or commands hold elevated privileges, the attacker receives explicit instructions on how the system categorizes its security controls, effectively turning an authentication bypass into a reconnaissance advantage that facilitates targeted privilege escalation attacks against other parts of the infrastructure.
The operational impact of this vulnerability is significant as it undermines the fundamental principle of least privilege within the Wazuh deployment. While the immediate action does not grant direct administrative access or allow for code execution, it serves as a critical enabler for further exploitation. Attackers can use the retrieved RBAC catalog to identify high-value targets such as configuration management endpoints, agent control commands, or rule modification interfaces that are protected by stricter authorization checks. By understanding exactly which actions require elevated permissions and how they are named in the API, an attacker can craft precise requests aimed at exploiting other potential weaknesses or misconfigurations within those privileged areas. This transforms a simple information leak into a strategic tool for lateral movement and deeper compromise of the security monitoring infrastructure, potentially allowing attackers to disable alerts, tamper with logs, or install backdoors without detection by standard audit mechanisms that rely on RBAC integrity.
This vulnerability aligns closely with CWE-284 Improper Access Control, as it involves failing to restrict access to resources based on user roles. Furthermore, the exploitation technique maps directly to MITRE ATT&CK techniques such as T1069 Permission Groups Discovery and T1530 Data from Cloud Storage Object or Internal Network Service Discovery, depending on how the retrieved data is utilized in a broader attack chain. The disclosure of internal API structures allows adversaries to perform systematic discovery of security controls, which is a common precursor step before attempting more destructive actions like privilege escalation or persistence establishment.
To mitigate this risk, organizations running Wazuh versions prior to 4.14.8 must upgrade immediately to version 4.14.8 or later where the authorization checks on these endpoints have been corrected. In environments where immediate patching is not feasible due to operational constraints, temporary mitigations should be implemented at the network perimeter level. This includes configuring firewalls or reverse proxies to block external access to the /security/actions and /security/resources API paths for all non-administrative users. Additionally, implementing strict IP whitelisting for administrative interfaces can reduce the attack surface by ensuring that only trusted management stations can interact with sensitive configuration endpoints. Regular auditing of RBAC policies and monitoring for unusual GET requests against security metadata endpoints should also be enforced to detect any potential exploitation attempts in real-time.