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

CVE-2026-61783 is an information disclosure vulnerability in Wazuh, an open-source XDR and SIEM platform, caused by an incorrect RBAC authorization check that allows authenticated low-privilege users to read the cluster secret (cluster.key) in cleartext. It affects Wazuh versions 4.14.0 through 4.14.6 and was published on August 28, 2026. The vulnerability was fixed in version 4.14.7. It carries a CVSS v4.0 base score of 7.0 (High) (Wazuh Advisory).

The root cause is an incorrect authorization check (CWE-863) combined with sensitive information exposure (CWE-200) in the _has_update_permissions() function within framework/wazuh/rbac/decorators.py. The mask_sensitive_config() decorator suppresses masking of sensitive values only when _has_update_permissions() returns False; however, this gate checks only whether a manager:update_config or cluster:update_config RBAC rule exists in the permission map — it never inspects whether the rule's effect is allow or deny. Because PreProcessor.process_policy() stores the raw effect string (including 'deny') as a non-empty dict entry, a user with an explicit deny rule on config updates is treated as having update permission, which disables masking. An attacker with a low-privilege account hardened with a deny rule can then issue a single authenticated GET /manager/configuration?raw=true (standalone) or GET /cluster/{node_id}/configuration?raw=true (clustered) request to receive the verbatim ossec.conf XML containing cluster.key in cleartext (Wazuh Advisory, Fix Commit).

Successful exploitation exposes the cluster.key — the shared secret used to authenticate and encrypt inter-node communication on Wazuh cluster port 1516/TCP — to any authenticated low-privilege user whose role includes an explicit deny on config-update actions. Disclosure of this key could enable an attacker with network access to the cluster port to impersonate cluster nodes, potentially compromising the integrity of the entire Wazuh deployment and the security telemetry it processes. There is no direct integrity or availability impact from the vulnerability itself, but the exposed credential creates significant downstream risk for cluster environments (Wazuh Advisory).

A proof-of-concept exploit is publicly available in the Wazuh GitHub security advisory, consisting of a complete curl/jq bash script that creates the necessary RBAC policies and users, authenticates, and retrieves the cluster key in cleartext. No in-the-wild exploitation has been observed as of the time of reporting. The vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.0024 (low probability of near-term exploitation), and exploitation requires an authenticated account with specific RBAC configuration (Wazuh Advisory).

1. Obtain or create a low-privilege account: Authenticate to the Wazuh API as an administrator and create a user (e.g., limited_user) with a role that includes manager:read (allow) and manager:update_config (deny) policies.
2. Assign the deny policy: Use the Wazuh API to create the deny policy and attach it to the user's role — this is the key step that inadvertently disables masking.
3. Authenticate as the low-privilege user: Obtain a JWT token by authenticating as limited_user via POST /security/user/authenticate?raw=true.
4. Request raw configuration: Send GET /manager/configuration?raw=true (standalone) or GET /cluster/{node_id}/configuration?raw=true (clustered) with the JWT bearer token.
5. Extract cluster.key: Parse the returned verbatim ossec.conf XML to extract the <key> value within the <cluster> block, which is returned in cleartext instead of being masked as *****.
6. Leverage the secret: With the cluster key and access to port 1516/TCP, potentially impersonate cluster nodes or intercept inter-node traffic (Wazuh Advisory).

• Network: Authenticated GET requests to /manager/configuration?raw=true or /cluster/{node_id}/configuration?raw=true from accounts that are not expected to access raw configuration; unusual API calls from low-privilege service accounts.
• Logs: Wazuh API access logs showing requests to the configuration endpoint with raw=true parameter from non-administrative users; log entries for RBAC policy creation assigning both allow read and deny update-config policies to the same role in rapid succession.
• API Activity: Creation of new security policies (POST /security/policies) and roles (POST /security/roles) followed shortly by a raw configuration read from the newly created user account (Wazuh Advisory).

Upgrade Wazuh to version 4.14.7, which fixes the vulnerability by modifying _has_update_permissions() to check that at least one resource grant carries an allow effect before treating the action as permitted (any(effect == 'allow' for effect in action_map.values())). As a temporary workaround for affected versions, avoid assigning explicit deny rules for manager:update_config or cluster:update_config to read-only accounts, as this paradoxically disables masking; instead, simply omit the update-config action from the role entirely. Additionally, restrict API access to the configuration endpoint at the network level to only trusted administrative hosts (Wazuh Advisory, Fix Commit).