CVE-2026-61783

Wazuh managers in versions 4.14.0 through 4.14.6 contain a sensitive-information disclosure flaw: the mask_sensitive_config() decorator skips masking whenever the requesting user holds any manager:update_config or cluster:update_config RBAC rule, and the permission check never inspects whether that rule's effect is allow or deny. Because deny rules are stored as real policy entries, a low-privilege read-only account that has been hardened with an explicit deny on config updates is incorrectly counted as having update permission, which disables masking entirely. Such a user can then send a single authenticated GET request to the configuration endpoint with raw=true and receive the verbatim ossec.conf XML, including the cluster.key secret in cleartext, while the same account without the deny rule would see the value masked. Any organization running an affected 4.14.x version with RBAC deny rules applied to read-only users is affected; no public proof-of-concept is known, exploitation has not been reported in the wild, and the fix is available in version 4.14.7.

What to do: Upgrade to Wazuh 4.14.7. As an interim mitigation, audit RBAC policies and remove explicit deny rules for manager:update_config/cluster:update_config from read-only users (rely on the absence of an allow rule instead), and restrict network access to the Wazuh manager API (default TCP 55000) to trusted clients. Review manager API access logs for raw=true configuration reads and rotate the cluster.key on any manager where exposure is suspected.