CVE-2026-61802: 
Wazuh Server vulnerability analysis and mitigation

CVE-2026-61802 is a sensitive information disclosure vulnerability in Wazuh's REST API that allows low-privilege authenticated users to retrieve the cleartext cluster authentication key. It affects Wazuh versions 4.14.0 through 4.14.6 (wazuh-manager package), and was published on August 18, 2026. The root cause is a missing @mask_sensitive_config decorator on the GET /cluster/local/config endpoint, which every sibling config-read endpoint correctly applies. It carries a CVSS v3.1 base score of 6.5 (Medium), though the realistic end-state severity via chained cluster-peer RCE is rated 9.x (Wazuh Advisory).

The vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-522 (Insufficiently Protected Credentials). Wazuh's REST API uses a mask_sensitive_config decorator to redact SENSITIVE_FIELD_PATHS — specifically authd.pass and cluster.key — from configuration responses for users lacking update-config permission. All config-read endpoints apply this decorator except GET /cluster/local/config, backed by read_config_wrapper() in framework/wazuh/cluster.py, which only imports expose_resources and async_list_handler and is gated solely by the cluster:read permission. As a result, any user with the default readonly or cluster_readonly role — which explicitly denies update-config — can call this endpoint and receive the 32-character cluster key in cleartext. The fix, committed in GitHub commit 1c55af2, adds @mask_sensitive_config() to read_config_wrapper() and converts the config dict to a plain dict copy to prevent cache poisoning (Wazuh Advisory, GitHub Commit).

Successful exploitation allows any low-privilege API account (e.g., readonly or cluster_readonly role) to obtain the Wazuh cluster's pre-shared authentication key in cleartext over the network. This key authenticates and encrypts master-to-worker cluster traffic on port 1516 (default). Possession of the key, combined with network access to the cluster port, satisfies the authentication precondition for previously disclosed Critical cluster-peer RCE chains (GHSA-m8rw-v4f6-8787, GHSA-r4f7-v3p6-79jm, CVE-2026-25769, CVE-2026-25770, CVE-2026-30893), enabling an attacker to achieve root-level remote code execution and arbitrary file write across all cluster nodes (Wazuh Advisory).

A proof-of-concept reproduction sequence is publicly documented in the Wazuh security advisory, requiring only four steps with standard HTTP tooling and no special conditions or timing requirements. The EPSS score is 0.00401 (low probability of near-term exploitation), and there is no evidence of in-the-wild exploitation at this time. The vulnerability is not currently listed in the CISA KEV catalog. NVD SSVC classifies exploitation status as "poc" with technical impact "partial" and automatable as "no" (Wazuh Advisory).

1. Identify a target: Locate a Wazuh manager running versions 4.14.0–4.14.6 in cluster mode (i.e., with a real <key> configured in ossec.conf). The Wazuh REST API is typically exposed on port 55000.
2. Obtain or create a low-privilege account: Use or create an API user assigned the default readonly or cluster_readonly role — no elevated permissions are required.
3. Authenticate to the API: Send a POST /security/user/authenticate request with the low-privilege credentials to obtain a JWT token:

   POST https://<wazuh-manager>:55000/security/user/authenticate
   Authorization: Basic <base64(user:pass)>

4. Call the vulnerable endpoint: Use the JWT to call GET /cluster/local/config:

   GET https://<wazuh-manager>:55000/cluster/local/config
   Authorization: Bearer <JWT>

5. Extract the cleartext cluster key: The response body contains data.affected_items[0].key with the real cluster key in cleartext, while the equivalent GET /manager/configuration?section=cluster returns the same field masked as ***.
6. Leverage for cluster-peer RCE: Use the recovered cluster key to authenticate as a cluster peer on port 1516 and exploit previously disclosed RCE chains (GHSA-m8rw-v4f6-8787, GHSA-r4f7-v3p6-79jm) to achieve root-level code execution across cluster nodes (Wazuh Advisory).

• Network: Unexpected or repeated GET /cluster/local/config requests in Wazuh API access logs from accounts with readonly or cluster_readonly roles; unusual inbound connections to the cluster port (default TCP 1516) from non-cluster IP addresses.
• Logs: Wazuh API access logs (/var/ossec/logs/api.log) showing GET /cluster/local/config calls by low-privilege users; compare against GET /manager/configuration calls — legitimate admins typically use the latter.
• Authentication: Multiple POST /security/user/authenticate requests followed immediately by GET /cluster/local/config from the same source IP, especially from accounts not expected to query cluster configuration.
• Cluster Traffic: New or unexpected cluster peer connections on port 1516 from IPs not belonging to known cluster nodes, which may indicate use of the stolen key to impersonate a cluster peer (Wazuh Advisory).

Upgrade Wazuh to version 4.14.7 or later, which applies the @mask_sensitive_config() decorator to read_config_wrapper() and resolves the disclosure (Wazuh Advisory, GitHub Commit). For organizations unable to patch immediately, restrict API access to GET /cluster/local/config to trusted administrative users only via network controls or API gateway rules, and audit API logs for unauthorized access to this endpoint. Additionally, implement network segmentation to limit access to the cluster port (default TCP 1516) to known cluster node IPs only, and consider rotating the cluster key if unauthorized access to the endpoint is suspected.

The vulnerability was reported by security researchers evilgensec and geo-chen and published by Wazuh maintainer vikman90 via GitHub Security Advisories on August 18, 2026. The advisory itself highlights the severity escalation potential — noting that while the direct CVSS score is 6.5 (Medium), the realistic end-state via chained cluster-peer RCE advisories is 9.x Critical — and explicitly calls out that Wazuh's own masking control was designed to prevent exactly this type of disclosure (Wazuh Advisory).