EUVD-2026-45978Severity by source
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Network-reachable cluster channel with low complexity, but requires the shared cluster key (PR:H); RBAC-context escape gives S:C and total C/I/A impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Lifecycle Timeline
7DescriptionNVD
Wazuh is a free and open source platform used for threat prevention, detection, and response. Prior to version 4.14.5, issues in the Cluster Distributed API (DAPI) handling allow a cluster peer, or any actor able to authenticate to the cluster channel using the shared cluster key, to make the master node deserialize an attacker-controlled callable and execute it under an attacker-controlled RBAC context. The cluster code in framework/wazuh/core/cluster/common.py deserializes JSON with as_wazuh_object(), which resolves any callable whose top-level package is wazuh or api (an overly broad allowlist controlled only by ALLOWED_CALLABLES_PACKAGES), and DAPI requests handled in framework/wazuh/core/cluster/dapi/dapi.py accept a client-supplied rbac_permissions value that run_local() applies as the global RBAC context, so supplying an rbac_mode of black causes authorization checks for expose_resources-protected functions to pass without any legitimate permission assignment. Combined, these allow privileged administrative actions on the master node such as arbitrary file writes under WAZUH_PATH, creation of new API users, and tampering with security.yaml, and can be chained into full manager compromise. This issue has been fixed in version 4.14.5.
AnalysisAI
Authenticated remote code execution in Wazuh's Cluster Distributed API (DAPI) lets any peer holding the shared cluster key coerce the master node into deserializing an attacker-controlled callable (CWE-502) and running it under a forged RBAC context, yielding full manager compromise. Rated CVSS 9.1 and affecting all cluster deployments from 4.0.0 up to the 4.14.5 fix, it combines an overly broad deserialization allowlist with client-controlled authorization to bypass permission checks entirely. SSVC records a proof-of-concept, so publicly available exploit code exists, though EPSS remains low at 0.19% (9th percentile), consistent with a signal that requires possession of the cluster key rather than opportunistic mass exploitation.
Technical ContextAI
Wazuh is an open-source security monitoring platform (SIEM/XDR) whose manager nodes form a master/worker cluster that communicate over an authenticated channel keyed by a shared cluster secret. The flaw is a classic Deserialization of Untrusted Data (CWE-502): framework/wazuh/core/cluster/common.py parses inbound JSON through as_wazuh_object(), which will resolve and instantiate any callable whose top-level package is 'wazuh' or 'api' - an allowlist governed solely by ALLOWED_CALLABLES_PACKAGES that is far too permissive. Compounding this, DAPI request handling in framework/wazuh/core/cluster/dapi/dapi.py trusts a client-supplied rbac_permissions value that run_local() installs as the process-global RBAC context; setting rbac_mode to 'black' makes expose_resources-protected authorization checks pass with no legitimate permission grant. The CPE cpe:2.3:a:wazuh:wazuh confirms the affected component is the core Wazuh application.
RemediationAI
Vendor-released patch: upgrade all Wazuh manager nodes to version 4.14.5 or later, per advisory GHSA-w2jj-pfq9-mh9p (https://github.com/wazuh/wazuh/security/advisories/GHSA-w2jj-pfq9-mh9p); this is the primary and only complete fix. Until every node is upgraded, reduce exposure by treating the shared cluster key as a high-value secret: rotate it, restrict the cluster port (default 1516/tcp) with firewall rules so only known manager nodes can connect, and place cluster traffic on an isolated management network - the trade-off is that mismatched keys or blocked peers will break cluster synchronization, so coordinate rotation across all nodes. Because the exploit hinges on a cluster peer or key holder reaching the master, also audit for unexpected cluster connections, monitor WAZUH_PATH for unauthorized file writes, and review security.yaml and the API user list for tampering or newly created accounts before and after patching.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
In the wazuh-slack active response script in Wazuh 4.2.x before 4.2.5, untrusted user agents are passed to a curl comman
A critical deserialization vulnerability in Wazuh's cluster mode allows attackers with access to any worker node to achi
The agent in OSSEC through 3.1.0 on Windows allows local users to gain NT AUTHORITY\SYSTEM access via Directory Traversa
CVE-2024-1243 is an improper input validation vulnerability in Wazuh agent for Windows (versions prior to 4.8.0) that al
Wazuh Manager in Wazuh through 4.1.5 is affected by a remote Integer Underflow vulnerability that might lead to denial o
NDJSON injection in Wazuh Manager before 5.0.0-beta3 lets any enrolled agent smuggle arbitrary OpenSearch bulk operation
Wazuh is a free and open source platform used for threat prevention, detection, and response. Rated critical severity (C
Privilege escalation in Wazuh Manager versions 3.9.0 through 4.14.2 allows authenticated cluster nodes to achieve unauth
Path-traversal-driven remote code execution in Wazuh 4.3.0 through 4.14.5 (and 5.0.0-beta1/beta2) lets a cluster peer th
Path-traversal-driven root code execution affects the Wazuh security platform's cluster synchronization layer in version
Arbitrary file read in Wazuh cluster deployments (4.0.0 through 4.14.5, and 5.0.0-beta1/beta2) lets a peer node that alr
Same weakness CWE-502 – Deserialization of Untrusted Data
View allSame technique Deserialization
View allShare
External POC / Exploit Code
Leaving vuln.today