CVE-2026-28220: 
Wazuh Server vulnerability analysis and mitigation

CVE-2026-28220 is a deserialization and RBAC context injection vulnerability in Wazuh's Cluster Distributed API (DAPI) that allows an authenticated cluster peer to execute privileged functions on the master node while bypassing authorization controls. It affects Wazuh versions >= 4.0.0 and was fixed in version 4.14.5. The vulnerability was published on July 20, 2026, with the GitHub Security Advisory (GHSA-w2jj-pfq9-mh9p) originally published July 16, 2026. It carries a CVSS v3.1 base score of 8.4 (High) (GitHub Advisory).

The vulnerability comprises two chained weaknesses. First, unsafe callable deserialization (CWE-502): the cluster code in framework/wazuh/core/cluster/common.py deserializes JSON using as_wazuh_object(), which resolves any {"__callable__": {"__module__": "...", "__name__": "..."}} structure into a live Python callable, with the only restriction being that the top-level package is wazuh or api — an overly broad allowlist (ALLOWED_CALLABLES_PACKAGES). Second, RBAC context injection (CWE-863): 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; supplying rbac_mode: "black" with no deny rules causes _black_expansion() in framework/wazuh/rbac/decorators.py to expand all required resources as allowed, bypassing @expose_resources-protected function authorization without any legitimate permission. An attacker must be able to authenticate to the cluster channel using the shared cluster key, and a proof-of-concept script (poc_dapi_3primitives.py) was verified against Wazuh 4.14.3 in a multi-node Docker deployment (GitHub Advisory).

Successful exploitation allows an authenticated cluster peer to perform arbitrary privileged administrative actions on the Wazuh master node, including arbitrary file writes under WAZUH_PATH (e.g., /var/ossec/etc/), creation of new backdoor API users with elevated privileges, and tampering with security.yaml (e.g., altering token timeouts and RBAC mode). These capabilities can be chained into full manager compromise, enabling an attacker to influence worker nodes and agents, disable or manipulate monitoring and response across the entire fleet, and establish persistent access via long-lived API credentials (GitHub Advisory).

1. Reconnaissance: Identify Wazuh cluster deployments with the master node's cluster port (default TCP 1516) accessible from a network-adjacent position. Confirm the target is running Wazuh >= 4.0.0 and < 4.14.5.
2. Obtain cluster key: Acquire the shared cluster key from the Wazuh cluster configuration (e.g., ossec.conf on a compromised worker node or via misconfigured access controls).
3. Authenticate to cluster channel: Using the shared cluster key, establish an authenticated connection to the master node's cluster port (TCP 1516), impersonating a legitimate cluster peer.
4. Craft malicious DAPI payload: Construct a DAPI request JSON payload containing:
   • A {"__callable__": {"__module__": "<wazuh_module>", "__name__": "<function>"}} structure targeting a privileged internal function (e.g., file write or user creation utilities).
   • A rbac_permissions field with rbac_mode: "black" and no deny rules to bypass RBAC authorization checks.
5. Submit payload to master: Send the crafted DAPI request to the master node via the cluster channel, triggering APIRequestQueue.run() to deserialize and execute the attacker-controlled callable under the injected RBAC context.
6. Execute primitives: Leverage the three demonstrated attack primitives:
   • P1 (Arbitrary file write): Write a malicious file (e.g., a web shell or config override) under /var/ossec/etc/.
   • P2 (Backdoor user creation): Create a new API user and authenticate via POST /security/user/authenticate to obtain a JWT token for persistent access.
   • P3 (Security config tampering): Overwrite security.yaml to alter RBAC mode or token settings, weakening the security posture.
7. Establish persistence and lateral movement: Use the newly created API credentials and modified security configuration to maintain access, pivot to worker nodes, and manipulate agent monitoring across the fleet (GitHub Advisory).

• Network: Unexpected inbound connections to the Wazuh cluster port (TCP 1516) from hosts not recognized as legitimate cluster peers; unusual outbound connections from the Wazuh master process.
• Logs: Cluster log entries showing DAPI requests with __callable__ JSON structures or rbac_mode: black in the payload around a suspicious timestamp; authentication events for newly created API users not provisioned by administrators.
• File System: Unexpected files created under /var/ossec/etc/ (e.g., poc_rce_marker.xml or unknown .xml/.conf files); modifications to /var/ossec/api/configuration/security/security.yaml with altered token_exp_timeout or rbac_mode values.
• API/Auth: New API users appearing in Wazuh user management that were not created through normal administrative processes; JWT tokens issued to unknown or unauthorized users via POST /security/user/authenticate.
• Process: Unusual child processes spawned by the Wazuh manager process; unexpected Python import activity involving internal wazuh or api module functions not part of normal cluster operations (GitHub Advisory).

Upgrade Wazuh to version 4.14.5 or later, which contains the official fix for this vulnerability. As interim mitigations: restrict network access to the cluster communication port (TCP 1516) to only trusted, known cluster peer IP addresses using firewall rules; implement strict access controls on the shared cluster key and rotate it if there is any possibility of exposure; and audit existing API users and security.yaml for unauthorized modifications. Monitor cluster logs for anomalous DAPI requests containing callable deserialization patterns or unexpected rbac_mode values (GitHub Advisory).