CVE-2026-61783: Wazuh Information Disclosure Vulnerability

CVE-2026-61783 Overview

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. CVE-2026-61783 is an information disclosure vulnerability [CWE-200] affecting Wazuh versions 4.14.0 through 4.14.6. An authenticated low-privilege user can read the cluster.key secret from the manager configuration through the API. The flaw resides in the mask_sensitive_config() decorator, which disables masking whenever any manager:update_config or cluster:update_config RBAC rule exists, including an explicit deny. A single authenticated GET request to the configuration endpoint with raw=true returns the verbatim ossec.conf XML with the cluster secret in cleartext. The issue is fixed in version 4.14.7.

Critical Impact
Read-only accounts hardened by explicit deny rules receive verbatim ossec.conf output containing the cluster secret, enabling lateral movement within the Wazuh cluster.

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-61783 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-61783

Vulnerability Analysis

The vulnerability is an information disclosure flaw in Wazuh's Role-Based Access Control (RBAC) permission evaluation logic. The mask_sensitive_config() decorator wraps the configuration read endpoint and redacts sensitive fields such as cluster.key before returning the response. Masking is applied only when the caller does not have update permissions on the manager or cluster configuration. The rationale is that a user permitted to modify the configuration would already see those values.

The underlying _has_update_permissions() helper decides whether to skip masking. It iterates the RBAC actions manager:update_config and cluster:update_config and returns true if any dictionary entry exists for those actions. It never inspects whether an entry's effect is allow or deny. Requesting the endpoint with raw=true returns the full ossec.conf XML.

Root Cause

The root cause is a broken access control check in framework/wazuh/rbac/decorators.py. Deny rules are stored as real entries in the permission map, so the presence check treats any restriction as evidence of an update capability. A read-only account hardened by an explicit deny on manager:update_config is misclassified as privileged, disabling the masking gate.

Attack Vector

Exploitation requires an authenticated account on the Wazuh API with an explicit deny rule for manager:update_config or cluster:update_config. The attacker issues a single GET request to the manager configuration endpoint with the raw=true parameter. The response contains ossec.conf with cluster.key in cleartext, which can then be used to authenticate to other cluster nodes.

python

# Patch: framework/wazuh/rbac/decorators.py
# fix(rbac): check effect value in _has_update_permissions
     perms = rbac.get() or {}
     for action in ("manager:update_config", "cluster:update_config"):
         action_map = perms.get(action)
-        if isinstance(action_map, dict) and len(action_map) > 0:
+        if isinstance(action_map, dict) and any(effect == 'allow' for effect in action_map.values()):
             return True
     return False

Source: GitHub Wazuh Commit 939f2e5

Detection Methods for CVE-2026-61783

Indicators of Compromise

Authenticated GET requests to the Wazuh manager configuration endpoint containing the raw=true query parameter from low-privileged accounts.
API responses that include a full ossec.conf XML payload returned to accounts that hold manager:update_config or cluster:update_config deny rules.
Unexpected use of cluster.key values to authenticate additional nodes to the Wazuh cluster.

Detection Strategies

Audit Wazuh API access logs for requests to configuration endpoints using raw=true and correlate with the caller's RBAC role.
Review RBAC policy definitions for roles that explicitly deny manager:update_config or cluster:update_config while still granting configuration read access.
Alert on any API response payload exceeding the expected size for masked configuration reads issued by non-administrative roles.

Monitoring Recommendations

Enable verbose Wazuh API request logging and forward events to a centralized SIEM for retention and query.
Track baseline configuration read patterns per role and flag deviations, especially requests originating from service or read-only accounts.
Monitor cluster.key usage by watching for cluster node join or authentication events initiated from unexpected hosts.

How to Mitigate CVE-2026-61783

Immediate Actions Required

Upgrade all Wazuh manager nodes running 4.14.0 through 4.14.6 to version 4.14.7.
Rotate the cluster.key value across all cluster nodes after patching, assuming prior exposure.
Review all custom RBAC policies and remove or rewrite deny rules that target manager:update_config or cluster:update_config.
Restrict access to the Wazuh API to trusted management networks only.

Patch Information

The fix is committed in framework/wazuh/rbac/decorators.py and shipped in Wazuh 4.14.7. The patched _has_update_permissions() now iterates the RBAC action map and returns true only when at least one entry has an effect of allow. See the GitHub Security Advisory GHSA-vjcq-cf36-f5gx and the upstream commit for full technical details.

Workarounds

Remove explicit deny rules for manager:update_config and cluster:update_config from all non-administrative roles until the upgrade is applied.
Rely on default-deny behavior by omitting update actions entirely from restricted roles rather than adding explicit deny entries.
Limit low-privilege user access to configuration read endpoints through upstream network or reverse-proxy filtering.

bash

# Verify Wazuh manager version after upgrade
/var/ossec/bin/wazuh-control info | grep WAZUH_VERSION

# Rotate the cluster key on all nodes and restart the manager
sed -i "s|<key>.*</key>|<key>$(openssl rand -hex 16)</key>|" /var/ossec/etc/ossec.conf
systemctl restart wazuh-manager