Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-61802

CVE-2026-61802: Wazuh Information Disclosure Vulnerability

CVE-2026-61802 is an information disclosure flaw in Wazuh that exposes the cleartext cluster key to low-privilege users. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-61802 Overview

CVE-2026-61802 is an information disclosure vulnerability in Wazuh, an open-source security platform providing unified XDR and SIEM protection. Versions 4.14.0 through 4.14.6 expose the cleartext cluster key through the GET /cluster/local/config REST API endpoint. The endpoint is gated only by the cluster:read permission and omits the mask_sensitive_config decorator applied to sibling endpoints. Any account with the default readonly or cluster_readonly role can therefore retrieve the shared secret used to authenticate and encrypt inter-node cluster traffic. The disclosed key satisfies the authentication precondition for previously documented cluster-peer remote code execution chains. This issue is classified as [CWE-200] Information Exposure and is fixed in version 4.14.7.

Critical Impact

A low-privilege API user can extract the Wazuh cluster key in cleartext, providing the authentication material required to pivot into cluster-peer RCE chains.

Affected Products

  • Wazuh 4.14.0
  • Wazuh 4.14.1 through 4.14.5
  • Wazuh 4.14.6

Discovery Timeline

  • 2026-08-28 - CVE-2026-61802 published to NVD
  • 2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-61802

Vulnerability Analysis

The Wazuh REST API implements a masking control named mask_sensitive_config that redacts fields such as authd.pass and cluster.key from configuration responses. The decorator applies when the caller lacks the update-config permission. Every configuration-read endpoint in the API carries this decorator except GET /cluster/local/config. That endpoint is backed by the read_config_wrapper function and returns the local node's cluster configuration verbatim. Sibling endpoints return the same underlying value with the key masked. The cluster key authenticates and encrypts traffic between Wazuh cluster nodes, so its disclosure to any authenticated caller enables impersonation of a legitimate cluster peer.

Root Cause

The root cause is a missing decorator on a single API handler. The read_config_wrapper function in framework/wazuh/cluster.py was decorated only with @expose_resources(actions=['cluster:read'], ...) and did not carry @mask_sensitive_config(). RBAC roles such as readonly and cluster_readonly are explicitly denied update-config so that their holders cannot view secrets. Because the masking logic was never invoked on this endpoint, the RBAC denial was bypassed and the cleartext cluster.key was returned in the response body.

Attack Vector

An attacker requires a valid API account with the cluster:read action, which the default readonly and cluster_readonly roles grant. The attacker issues an authenticated HTTP GET request to /cluster/local/config and parses the returned JSON to extract cluster.key. With the key in hand, the attacker can authenticate to cluster peers and reach the remote code execution chains documented in prior Wazuh advisories.

python
 from wazuh.core.cluster.utils import get_cluster_status, read_cluster_config, read_config
 from wazuh.core.exception import WazuhError, WazuhResourceNotFound
 from wazuh.core.results import AffectedItemsWazuhResult, WazuhResult
-from wazuh.rbac.decorators import expose_resources, async_list_handler
+from wazuh.rbac.decorators import expose_resources, async_list_handler, mask_sensitive_config

 cluster_enabled = not read_cluster_config(from_import=True)['disabled']
 node_id = get_node().get('node') if cluster_enabled else None
 node_type = get_node().get('type') if cluster_enabled else 'master'


+@mask_sensitive_config()
 @expose_resources(actions=['cluster:read'], resources=[f'node:id:{node_id}'])
 def read_config_wrapper() -> AffectedItemsWazuhResult:
     """Wrapper for read_config.

Source: Wazuh commit 1c55af25. The patch adds the @mask_sensitive_config() decorator to read_config_wrapper, aligning its behavior with the other config-read endpoints.

Detection Methods for CVE-2026-61802

Indicators of Compromise

  • Authenticated HTTP GET requests to /cluster/local/config originating from accounts assigned the readonly or cluster_readonly role.
  • API responses from /cluster/local/config whose body contains a non-redacted cluster.key value rather than a masked placeholder.
  • Unexpected cluster-peer handshake attempts from hosts that are not registered Wazuh worker or master nodes.

Detection Strategies

  • Audit the Wazuh API access log for requests to the /cluster/local/config path and correlate the calling user with their assigned RBAC role.
  • Compare responses from /cluster/local/config and /cluster/{node_id}/configuration for the same node; divergent masking behavior indicates the unpatched endpoint.
  • Alert on API token issuance or use by low-privilege accounts followed by access to cluster configuration endpoints.

Monitoring Recommendations

  • Enable verbose API request logging on the Wazuh manager and forward logs to a central analytics platform for retention and query.
  • Monitor cluster port 1516/tcp for connection attempts from IP addresses outside the approved cluster peer allowlist.
  • Track creation and role assignment events for Wazuh API users, particularly assignments of readonly and cluster_readonly.

How to Mitigate CVE-2026-61802

Immediate Actions Required

  • Upgrade Wazuh manager nodes to version 4.14.7 or later, which applies the mask_sensitive_config decorator to read_config_wrapper.
  • Rotate the cluster.key value on all nodes after patching, since any prior disclosure remains valid until the key is changed.
  • Review API user inventory and revoke accounts or tokens that no longer require cluster read access.

Patch Information

The fix is committed in 1c55af25ebb160bddbde591efc19bb77b01282e7 and shipped in Wazuh 4.14.7. Refer to the Wazuh security advisory GHSA-chmg-89pf-2q82 for the vendor's disclosure and the upstream commit for the code change.

Workarounds

  • Restrict network access to the Wazuh API so that only trusted management hosts can reach it, reducing the pool of accounts that could invoke the endpoint.
  • Create a custom RBAC policy that explicitly denies cluster:read on node:id:* for the readonly and cluster_readonly roles until the patch is deployed.
  • Place the Wazuh cluster network segment behind a firewall rule set that only permits peer traffic between known cluster node IP addresses.
bash
# Rotate cluster.key on every node after patching, then restart the manager
sudo sed -i "s/<key>.*<\/key>/<key>$(openssl rand -hex 16)<\/key>/" /var/ossec/etc/ossec.conf
sudo systemctl restart wazuh-manager

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.