CVE-2026-61783: Information Disclosure

Description

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.14.0 through 4.14.6, an authenticated low-privilege user can read the cluster secret from the manager configuration because the logic that masks sensitive values is disabled by any update-config RBAC rule, including an explicit deny. The mask_sensitive_config() decorator applies masking only when _has_update_permissions() returns false, but that gate treats a user as able to update the config whenever a manager:update_config or cluster:update_config rule exists, without ever checking whether the rule's effect is allow or deny. Because a deny rule is stored as a real entry, a read-only account that is hardened by explicitly denying config edits is counted as having update permission, which turns masking off. A single authenticated GET request to the configuration endpoint with raw=true then returns the verbatim ossec.conf XML with cluster.key in clear, whereas an otherwise identical account without the deny rule sees the value masked. This issue is fixed in version 4.14.7.

Is your site exposed to CVE-2026-61783?

Run a free security scan — no signup, results in seconds.

Weakness Type (CWE)

CWE-200 CWE-200

CWE-863 Incorrect Authorization

References

Other References

https://github.com/wazuh/wazuh/commit/939f2e52afff8fbeb7b0894f3f1417eb6c395db3 https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx

Frequently Asked Questions

What is CVE-2026-61783? +

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.14.0 through 4.14.6, an authenticated low-privilege user can read the cluster secret from the manager configuration because the logic that masks sensitive values is disabled by any update-config RBAC rule, including an explicit deny. The mask_sensitive_config() decorator applies masking only when _has_update_permissions() returns false, but that gate treats a user as able to update the config whenever a manager:update_config or cluster:update_config rule exists, without ever checking whether the rule's effect is allow or deny. Because a deny rule is stored as a real entry, a read-only account that is hardened by explicitly denying config edits is counted as having update permission, which turns masking off. A single authenticated GET request to the configuration endpoint with raw=true then returns the verbatim ossec.conf XML with cluster.key in clear, whereas an otherwise identical account without the deny rule sees the value masked. This issue is fixed in version 4.14.7.

How do I check if I'm vulnerable to CVE-2026-61783? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2025-15625

Unauthenticated user is able to execute arbitrary SQL commands in Sparx Pro Cloud Server database in certain cases.

CVE-2026-22051

StorageGRID (formerly StorageGRID Webscale) versions prior to 11.9.0.13 and 12.0.0.6 are susceptible to a Information Disclosure vulnerability. Successful exploit could …

CVE-2026-41186

When Calico's shared debug server is enabled (disabled by default), the Calico kube-controllers and Goldmane components bind their Go pprof …

CVE-2026-54396

An information disclosure vulnerability exists in the MISP AuthKey edit functionality. When a validation error occurs during an AuthKey edit …

CVE-2026-13230

An information disclosure vulnerability was identified in TP-Link Kasa EC70 v4 and EC71 v4 in the local discovery mechanism, which …

CVE-2026-53912

Cerebrate before version 1.37 exposed credential material from self-registration requests. The self-registration workflow stored the registrant’s hashed password in the …

CVE-2026-61783