CVE-2026-28220: Wazuh Platform RCE Vulnerability

CVE-2026-28220 Overview

CVE-2026-28220 is an insecure deserialization vulnerability in Wazuh, a free and open source platform for threat prevention, detection, and response. The flaw exists in the Cluster Distributed API (DAPI) handling prior to version 4.14.5. Any actor able to authenticate to the cluster channel using the shared cluster key can force the master node to deserialize an attacker-controlled callable. The callable then executes under an attacker-controlled Role-Based Access Control (RBAC) context. Successful exploitation allows arbitrary file writes under WAZUH_PATH, creation of new API users, and tampering with security.yaml, chaining into full manager compromise. The issue is tracked under [CWE-502] and has been fixed in version 4.14.5.

Critical Impact
An authenticated cluster peer can execute arbitrary callables on the master node under a bypassed RBAC context, resulting in full Wazuh manager compromise.

Affected Products

Wazuh versions prior to 4.14.5
Wazuh Cluster Distributed API (DAPI) component
Wazuh manager master node deployments running in clustered mode

Discovery Timeline

2026-07-20 - CVE-2026-28220 published to NVD
2026-07-21 - Last updated in NVD database

Technical Details for CVE-2026-28220

Vulnerability Analysis

The vulnerability originates in the Wazuh cluster inter-node communication logic. The cluster code in framework/wazuh/core/cluster/common.py deserializes JSON payloads using the as_wazuh_object() helper. This helper resolves any callable whose top-level package is wazuh or api. The allowlist controlled by ALLOWED_CALLABLES_PACKAGES is overly broad and permits resolution of internal administrative functions.

DAPI requests handled in framework/wazuh/core/cluster/dapi/dapi.py accept a client-supplied rbac_permissions value. The run_local() function applies this value as the global RBAC context for the request. When an attacker supplies an rbac_mode of black, authorization checks for expose_resources-protected functions pass without any legitimate permission assignment.

Root Cause

Two root causes combine to enable exploitation. First, the deserialization allowlist trusts entire top-level packages rather than a curated set of safe callables. Second, DAPI treats client-supplied RBAC context as authoritative, allowing peers to declare their own permissions instead of deriving them from authenticated identity.

Attack Vector

An attacker must possess the shared cluster key or otherwise authenticate to the cluster channel from an adjacent network position. Once authenticated, the attacker sends a crafted DAPI request containing a serialized callable reference and an rbac_mode of black. The master node resolves the callable, applies the attacker-defined RBAC context, and executes the function. Attackers can invoke privileged administrative functions to write arbitrary files under WAZUH_PATH, create new API users, and modify security.yaml.

See the GitHub Security Advisory GHSA-w2jj-pfq9-mh9p for the full technical writeup.

Detection Methods for CVE-2026-28220

Indicators of Compromise

Unexpected DAPI requests containing rbac_mode set to black from cluster peers
Unauthorized modifications to security.yaml or creation of new API users outside change windows
New or modified files under WAZUH_PATH written by the master node without corresponding administrator activity
Cluster authentication events from unexpected source addresses using the shared cluster key

Detection Strategies

Inspect cluster traffic for JSON payloads referencing callables in the wazuh or api packages that are not part of normal cluster synchronization
Correlate DAPI request logs with the source cluster peer identity and flag deviations from baseline behavior
Audit Wazuh API user creation events and compare against approved change tickets

Monitoring Recommendations

Forward Wazuh manager and cluster logs to a centralized SIEM for retention and correlation
Alert on any process spawned by the Wazuh manager that writes to security.yaml or the API users database
Monitor network segments carrying cluster traffic for unexpected peers attempting authentication

How to Mitigate CVE-2026-28220

Immediate Actions Required

Upgrade all Wazuh manager nodes to version 4.14.5 or later immediately
Rotate the shared cluster key after upgrade to invalidate any previously compromised credentials
Audit security.yaml, API users, and files under WAZUH_PATH for unauthorized changes
Restrict network access to the cluster channel to known manager nodes only

Patch Information

The issue has been fixed in Wazuh version 4.14.5. The patch tightens the deserialization allowlist and prevents client-supplied RBAC context from bypassing authorization checks. Refer to the Wazuh GitHub Security Advisory for full remediation details.

Workarounds

Isolate cluster traffic on a dedicated management VLAN accessible only to authorized manager nodes
Enforce firewall rules that permit cluster port connections only from known peer IP addresses
Rotate the shared cluster key regularly and store it in a secrets manager with strict access controls

bash

# Configuration example: restrict cluster port access with iptables
# Replace <peer_ip> with authorized manager node addresses and <cluster_port> with the configured port
iptables -A INPUT -p tcp --dport <cluster_port> -s <peer_ip> -j ACCEPT
iptables -A INPUT -p tcp --dport <cluster_port> -j DROP