CVE-2026-61783 (GCVE-0-2026-61783)

Vulnerability from cvelistv5 – Published: 2026-08-27 23:19 – Updated: 2026-08-28 14:52
VLAI
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.
SSVC
Exploitation: poc Automatable: no Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-28 14:52 UTC
CWE
  • CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
  • CWE-863 - Incorrect Authorization
References
Impacted products
Vendor Product Version CPE status
wazuh wazuh Affected: >= 4.14.0, < 4.14.7
guessed Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-61783",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-28T14:52:38.564720Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-28T14:52:45.579Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "wazuh",
          "vendor": "wazuh",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 4.14.0, \u003c 4.14.7"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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 \u00a0manager:update_config\u00a0 or \u00a0cluster:update_config\u00a0 rule exists, without ever checking whether the rule\u0027s 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 \u00a0raw=true\u00a0 then returns the verbatim ossec.conf XML with \u00a0cluster.key\u00a0 in clear, whereas an otherwise identical account without the deny rule sees the value masked. This issue is fixed in version 4.14.7."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-200",
              "description": "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-863",
              "description": "CWE-863: Incorrect Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-27T23:19:18.214Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx"
        },
        {
          "name": "https://github.com/wazuh/wazuh/commit/939f2e52afff8fbeb7b0894f3f1417eb6c395db3",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/wazuh/wazuh/commit/939f2e52afff8fbeb7b0894f3f1417eb6c395db3"
        }
      ],
      "source": {
        "advisory": "GHSA-vjcq-cf36-f5gx",
        "discovery": "UNKNOWN"
      },
      "title": "Wazuh: RBAC permission-effect check in mask_sensitive_config allows low-privilege users to read cluster.key"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-61783",
    "datePublished": "2026-08-27T23:19:18.214Z",
    "dateReserved": "2026-07-10T20:06:05.616Z",
    "dateUpdated": "2026-08-28T14:52:45.579Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-61783",
      "date": "2026-08-29",
      "epss": "0.00239",
      "percentile": "0.1478"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-61783\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-08-28T00:18:07.997\",\"lastModified\":\"2026-08-28T16:18:20.037\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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 \u00a0manager:update_config\u00a0 or \u00a0cluster:update_config\u00a0 rule exists, without ever checking whether the rule\u0027s 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 \u00a0raw=true\u00a0 then returns the verbatim ossec.conf XML with \u00a0cluster.key\u00a0 in clear, whereas an otherwise identical account without the deny rule sees the value masked. This issue is fixed in version 4.14.7.\"}],\"affected\":[{\"source\":\"security-advisories@github.com\",\"affectedData\":[{\"vendor\":\"wazuh\",\"product\":\"wazuh\",\"versions\":[{\"version\":\"\u003e= 4.14.0, \u003c 4.14.7\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV40\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"4.0\",\"vectorString\":\"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X\",\"baseScore\":7.0,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"attackRequirements\":\"PRESENT\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"vulnConfidentialityImpact\":\"HIGH\",\"vulnIntegrityImpact\":\"NONE\",\"vulnAvailabilityImpact\":\"NONE\",\"subConfidentialityImpact\":\"HIGH\",\"subIntegrityImpact\":\"NONE\",\"subAvailabilityImpact\":\"NONE\",\"exploitMaturity\":\"NOT_DEFINED\",\"confidentialityRequirement\":\"NOT_DEFINED\",\"integrityRequirement\":\"NOT_DEFINED\",\"availabilityRequirement\":\"NOT_DEFINED\",\"modifiedAttackVector\":\"NOT_DEFINED\",\"modifiedAttackComplexity\":\"NOT_DEFINED\",\"modifiedAttackRequirements\":\"NOT_DEFINED\",\"modifiedPrivilegesRequired\":\"NOT_DEFINED\",\"modifiedUserInteraction\":\"NOT_DEFINED\",\"modifiedVulnConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedVulnIntegrityImpact\":\"NOT_DEFINED\",\"modifiedVulnAvailabilityImpact\":\"NOT_DEFINED\",\"modifiedSubConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedSubIntegrityImpact\":\"NOT_DEFINED\",\"modifiedSubAvailabilityImpact\":\"NOT_DEFINED\",\"Safety\":\"NOT_DEFINED\",\"Automatable\":\"NOT_DEFINED\",\"Recovery\":\"NOT_DEFINED\",\"valueDensity\":\"NOT_DEFINED\",\"vulnerabilityResponseEffort\":\"NOT_DEFINED\",\"providerUrgency\":\"NOT_DEFINED\"}}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2026-08-28T14:52:38.564720Z\",\"id\":\"CVE-2026-61783\",\"options\":[{\"exploitation\":\"poc\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-200\"},{\"lang\":\"en\",\"value\":\"CWE-863\"}]}],\"references\":[{\"url\":\"https://github.com/wazuh/wazuh/commit/939f2e52afff8fbeb7b0894f3f1417eb6c395db3\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx\",\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-61783\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-08-28T14:52:38.564720Z\"}}}], \"references\": [{\"url\": \"https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx\", \"tags\": [\"exploit\"]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-08-28T14:52:23.409Z\"}}], \"cna\": {\"title\": \"Wazuh: RBAC permission-effect check in mask_sensitive_config allows low-privilege users to read cluster.key\", \"source\": {\"advisory\": \"GHSA-vjcq-cf36-f5gx\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV4_0\": {\"version\": \"4.0\", \"baseScore\": 7, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"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\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"PRESENT\", \"privilegesRequired\": \"LOW\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"NONE\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"NONE\", \"subConfidentialityImpact\": \"HIGH\", \"vulnConfidentialityImpact\": \"HIGH\"}}], \"affected\": [{\"vendor\": \"wazuh\", \"product\": \"wazuh\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003e= 4.14.0, \u003c 4.14.7\"}]}], \"references\": [{\"url\": \"https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx\", \"name\": \"https://github.com/wazuh/wazuh/security/advisories/GHSA-vjcq-cf36-f5gx\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/wazuh/wazuh/commit/939f2e52afff8fbeb7b0894f3f1417eb6c395db3\", \"name\": \"https://github.com/wazuh/wazuh/commit/939f2e52afff8fbeb7b0894f3f1417eb6c395db3\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"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 \\u00a0manager:update_config\\u00a0 or \\u00a0cluster:update_config\\u00a0 rule exists, without ever checking whether the rule\u0027s 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 \\u00a0raw=true\\u00a0 then returns the verbatim ossec.conf XML with \\u00a0cluster.key\\u00a0 in clear, whereas an otherwise identical account without the deny rule sees the value masked. This issue is fixed in version 4.14.7.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-200\", \"description\": \"CWE-200: Exposure of Sensitive Information to an Unauthorized Actor\"}]}, {\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-863\", \"description\": \"CWE-863: Incorrect Authorization\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-08-27T23:19:18.214Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-61783\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-28T14:52:45.579Z\", \"dateReserved\": \"2026-07-10T20:06:05.616Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-08-27T23:19:18.214Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…