Wazuh CVE-2026-61802

Exploitation requires a valid Wazuh API account assigned the readonly or cluster_readonly role (confirmed by CVSS PR:L). The affected endpoint is GET /cluster/local/config, which is gated only by the cluster:read permission - a permission held by both default low-privilege roles. The target must be running Wazuh 4.14.0-4.14.6 with cluster mode enabled, as the cluster key is only present and meaningful in clustered deployments. Because readonly and cluster_readonly are explicitly designed to deny update-config permission (the very control that should have triggered masking), these roles are commonly assigned to low-trust principals such as service accounts, read-only dashboards, and junior analysts, widening the realistic attacker pool beyond a narrowly defined insider threat. Unauthenticated exploitation is not possible per CVSS PR:L. The secondary RCE impact via cluster key reuse further requires network-level reachability to the Wazuh cluster bus port (default 1516), which may be an additional limiting factor in segmented environments.

The CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) accurately captures the direct impact of this vulnerability as a network-accessible, low-privilege information disclosure with high confidentiality impact. However, the operational risk substantially exceeds the base score in clustered Wazuh deployments: because the cluster key is the authentication precondition for cluster-peer RCE chains documented in prior advisories, obtaining it effectively bridges a low-privilege API read into a potential remote code execution path. EPSS data was not included in the provided input, so exploitation probability cannot be quantified. The vulnerability is not currently listed in the CISA KEV catalog, and no public proof-of-concept code has been identified at time of analysis. The low attack complexity and the fact that readonly roles are routinely assigned to service accounts, SOC analysts, and integrations means the attacker pool within any affected organization is broader than a high-privilege-only flaw. Organizations with multi-node Wazuh clusters running versions 4.14.0-4.14.6 should treat remediation as urgent given the asymmetric consequence of cluster key compromise relative to the low exploitation barrier.

An attacker who has obtained or been issued a low-privilege Wazuh API account (readonly or cluster_readonly role) sends an authenticated GET request to /cluster/local/config and receives a JSON response containing the cluster key in cleartext. The attacker then uses this key to impersonate a legitimate cluster node on the Wazuh cluster bus and exploits the pre-existing cluster-peer remote code execution chains documented in prior Wazuh security advisories to achieve code execution on master or worker nodes.