Skip to content
Heist/ feed
Back to feed
High

Wazuh: RBAC permission-effect check in mask_sensitive_config allows low-privilege users to read cluster.key

Type: advisorySources: OSV

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.

Products
Not specified
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2026-61783
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 23:22 UTC · Revision 1

Source evidence

Wazuh: RBAC permission-effect check in mask_sensitive_config allows low-privilege users to read cluster.key

core-osv · Original source

Published 27 Aug 2026, 23:19 UTC

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.

osv:CVE-2026-61783
Complete source record
{
  "id": "c3e55be0e112c8c80d0a7d2da906040a70163fc2e5c3e0f0ff706795e9d78852",
  "url": "https://osv.dev/vulnerability/CVE-2026-61783",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "Wazuh: RBAC permission-effect check in mask_sensitive_config allows low-privilege users to read cluster.key",
    "summary": "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.",
    "evidence": "osv:CVE-2026-61783",
    "products": [],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-61783",
      "aliases": [
        "CVE-2026-61783",
        "GHSA-vjcq-cf36-f5gx"
      ],
      "metrics": [
        {
          "type": "CVSS_V4",
          "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://github.com/wazuh/wazuh",
              "type": "GIT",
              "events": [
                {
                  "introduced": "e0707d735cc60b38da2723376a2f0faeffe697bb"
                },
                {
                  "fixed": "a42268a27c555d9348d5598fb8751eaf4c8e9024"
                },
                {
                  "fixed": "939f2e52afff8fbeb7b0894f3f1417eb6c395db3"
                }
              ],
              "database_specific": {
                "extracted_events": [
                  {
                    "cpe": "cpe:2.3:a:wazuh:wazuh:*:*:*:*:*:*:*:*",
                    "range": [
                      {
                        "introduced": "4.14.0"
                      },
                      {
                        "fixed": "4.14.7"
                      }
                    ],
                    "source": "CPE_RANGE"
                  },
                  {
                    "range": [
                      {
                        "fixed": "939f2e52afff8fbeb7b0894f3f1417eb6c395db3"
                      }
                    ],
                    "source": "REFERENCES_COMMIT"
                  }
                ]
              }
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-61783.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:40.347002154Z",
      "provider": "osv",
      "references": [
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/61xxx/CVE-2026-61783.json",
        "https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-61783",
        "https://github.com/wazuh/wazuh/commit/939f2e52afff8fbeb7b0894f3f1417eb6c395db3"
      ],
      "provider_metadata": {
        "cwe_ids": [
          "CWE-200",
          "CWE-863"
        ],
        "cna_assigner": "GitHub_M",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/61xxx/CVE-2026-61783.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-61783",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 507973,
  "published_at": "2026-08-27T23:19:18.214+00:00"
}