Description

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, a low-privilege API user can read the cleartext cluster key from a configuration endpoint that fails to redact it. The REST API provides a masking control, mask_sensitive_config, that redacts sensitive fields such as authd.pass and cluster.key from configuration responses for users who lack update-config permission, and every config-read endpoint carries this decorator except GET /cluster/local/config. That endpoint, backed by read_config_wrapper, is gated only by cluster:read and returns the local node's cluster configuration including the cleartext key, whereas its siblings return the same value masked. As a result, any account with the default readonly or cluster_readonly role, which is explicitly denied update-config precisely so it cannot view secrets, receives the real cluster key. Because the cluster key authenticates and encrypts traffic between cluster nodes, disclosing it to an unprivileged account provides the authentication precondition for the cluster-peer remote code execution chains established by prior advisories. This issue is fixed in version 4.14.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-28T02:16:21.907Z",
  "pubdate": "2026-08-28T02:16:21.907Z",
  "executiveSummary": "Wazuh versions 4.14.0 through 4.14.6 contain an information disclosure vulnerability within the REST API. The vulnerability originates from a failure to apply sensitivity redaction controls to the GET /cluster/local/config endpoint.\nThis flaw allows low-privilege users assigned with read-only roles to retrieve the cleartext cluster key, which is intended to be restricted to users with administrative update-config permissions.\nThe cluster key is a critical security credential used for authenticating and encrypting communication between nodes in a Wazuh cluster. Unauthorized disclosure of this key facilitates further exploitation, specifically providing the necessary authentication precondition for previously identified cluster-peer remote code execution (RCE) chains.\nThe vulnerability affects the API's configuration management logic, specifically the interaction between the security decorator mask_sensitive_config and the local node configuration retrieval function. Remediation requires upgrading the Wazuh platform to version 4.14.7 or later to ensure consistent redaction of sensitive configuration fields across all API endpoints.",
  "technicalDetails": "The root cause of this vulnerability is an inconsistent implementation of security decorators within the Wazuh REST API framework. Specifically, the API utilizes a mask_sensitive_config decorator designed to filter sensitive information, such as cluster.key and authd.pass, from configuration responses for users lacking the update-config permission.\nWhile most configuration-related endpoints properly employ this decorator, the GET /cluster/local/config endpoint, which is backed by the read_config_wrapper function, fails to implement this protection. Instead, the endpoint is only gated by the cluster:read permission. Consequently, users assigned with restricted roles, such as readonly or cluster_readonly—who are explicitly denied update-config privileges—are granted access to the raw, unmasked configuration object.\nThe attack flow involves an authenticated low-privileged user querying the /cluster/local/config endpoint via the REST API. Because the endpoint does not perform the required sensitivity filtering, the API returns a JSON response containing the full cluster configuration, including the cleartext cluster key. An attacker can perform this action using standard HTTP GET requests, provided they have valid low-privileged credentials.\nThe impact of this disclosure is severe due to the function of the cluster key within the Wazuh architecture. The key is fundamental to node-to-node communication security. By obtaining the cleartext key, an attacker can authenticate as a cluster node or intercept and manipulate encrypted inter-node traffic. Furthermore, this vulnerability acts as a critical prerequisite for advanced exploit chains, enabling an attacker to leverage known cluster-peer RCE vectors that otherwise would have been blocked by the lack of legitimate authentication credentials. The lack of redaction effectively bypasses the security policy intended to isolate sensitive cluster management secrets from standard read-only accounts."
}