CVE-2026-61783 in Wazuh
Summary
by MITRE • 08/28/2026
Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.14.0 through 4.14.6, an authenticated low-privilege user can read the cluster secret from the manager configuration because the logic that masks sensitive values is disabled by any update-config RBAC rule, including an explicit deny. The mask_sensitive_config() decorator applies masking only when _has_update_permissions() returns false, but that gate treats a user as able to update the config whenever a manager:update_config or cluster:update_config rule exists, without ever checking whether the rule's effect is allow or deny. Because a deny rule is stored as a real entry, a read-only account that is hardened by explicitly denying config edits is counted as having update permission, which turns masking off. A single authenticated GET request to the configuration endpoint with raw=true then returns the verbatim ossec.conf XML with cluster.key in clear, whereas an otherwise identical account without the deny rule sees the value masked. This issue is fixed in version 4.14.7.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
Wazuh serves as a comprehensive open-source security platform designed to deliver unified Extended Detection and Response (XDR) and Security Information and Event Management (SIEM) capabilities for endpoints and cloud workloads. Within the specific versions ranging from 4.14.0 through 4.14.6, a critical authentication bypass vulnerability exists that allows authenticated low-privilege users to access sensitive cluster configuration secrets. This flaw stems directly from an incorrect implementation of role-based access control logic within the application's backend service, specifically affecting how permission checks are evaluated against stored security policies. The core issue lies in the interaction between the RBAC engine and the function responsible for masking sensitive data fields during API responses.
The technical root cause is located in the mask_sensitive_config decorator, which is intended to obfuscate confidential values such as cluster keys before they are returned to the user interface or via API calls. This decorator relies on a helper function named _has_update_permissions() to determine whether masking should be applied. The logic within this helper function erroneously assumes that if any rule exists for manager:update_config or cluster:update_config, the user possesses update permissions. It fails to distinguish between allow and deny effects when evaluating these rules. Consequently, even if an administrator has explicitly denied a low-privilege user the ability to modify configurations via a dedicated deny rule, the system still registers this user as having update capabilities because the deny entry is stored as a valid RBAC policy entry rather than being treated as a negation of permission for masking purposes.
This logical error results in a significant operational impact where sensitive cryptographic material is exposed to unauthorized parties. An attacker with an authenticated low-privilege account, even one hardened by explicit denials on configuration changes, can issue a GET request to the configuration endpoint with the raw parameter set to true. This action triggers the flawed masking logic, causing the system to return the verbatim ossec.conf XML file containing the cluster.key in clear text. In contrast, an otherwise identical account without such deny rules would correctly see masked values due to proper permission evaluation. The exposure of the cluster key compromises the integrity and confidentiality of the Wazuh manager-cluster communication channel, potentially allowing attackers to impersonate agents or managers within the infrastructure.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves an authorization bypass that allows users to access resources they should not be permitted to view. It also relates to CWE-798 Use of Hard-coded Credentials if one considers the cluster key as sensitive configuration data improperly exposed due to logic errors rather than static hardcoding. In terms of attack vectors, this falls under MITRE ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate credentials with insufficient privileges to access restricted information. The flaw represents a classic case of logical error in permission evaluation where the presence of any rule overrides the specific intent of deny rules regarding data masking.
To mitigate this vulnerability, organizations running Wazuh versions 4.14.0 through 4.14.6 must immediately upgrade to version 4.14.7 or later, which contains the corrected logic for evaluating RBAC effects before applying sensitive value masking. Until an upgrade is feasible, administrators should review their RBAC policies to ensure that no low-privilege users have any rules related to manager:update_config or cluster:update_config, even if those rules are deny entries, as the current version cannot correctly interpret them. Additionally, monitoring for unusual GET requests to configuration endpoints with raw parameters enabled can help detect potential exploitation attempts in real-time. Regular audits of access control policies and strict adherence to the principle of least privilege remain essential practices to prevent similar logical flaws from leading to data exposure.