Potheeswaran 
A newly disclosed vulnerability in Wazuh’s cluster architecture shows how two seemingly separate design flaws can combine into a full manager takeover.
Tracked as CVE-2026-28220 and rated High severity, the flaw affects Wazuh deployments running version 4.0.0 and above, with a fix landing in 4.14.5. Security researcher vikman90 published the advisory (GHSA-w2jj-pfq9-mh9p) five days ago, crediting alimezar as reporter and maru1009 as finder.
At its core, the bug lets any cluster peer that holds the shared cluster key, whether a legitimate worker node or an attacker who’s compromised one, force the master node to execute arbitrary internal functions while spoofing its own administrative permissions.
Wazuh Cluster Flaw
The vulnerability chains two distinct weaknesses in Wazuh’s Distributed API (DAPI), the internal mechanism that lets cluster nodes forward management requests to the master.
Finding 1 – Unsafe Callable Deserialization (CWE-502): Wazuh’s cluster code deserializes incoming JSON using an object_hook called as_wazuh_object(). When it encounters a {"__callable__": ...} structure, it resolves the specified module and function name into a live, executable Python callable.
The only safeguard is that the top-level package must be wazuh or api a restriction so broad it still exposes a massive surface of internal functions to attacker selection.
This logic lives in framework/wazuh/core/cluster/common.py, with execution triggered in dapi.py via APIRequestQueue.run().
Finding 2 – RBAC Context Injection (CWE-863): DAPI requests carry an rbac_permissions field that the master trusts to set the authorization context for whatever function gets executed.
Because this context comes from the request payload rather than being derived server-side from a verified identity, an attacker can simply declare rbac_mode: "black" with no deny rules.
Wazuh’s RBAC decorator logic then expands all required resources as implicitly allowed authorization passes without any real permission ever being granted.
Individually, each flaw is serious. Combined, they let an attacker pick any privileged internal function and guarantee it passes authorization.
The published PoC script demonstrates three independent attack primitives against a live master node:
- Arbitrary file write under
WAZUH_PATH(verified by dropping a marker file in/var/ossec/etc/) - Creation of a backdoor API user, confirmed via a valid JWT authentication response
- Tampering with
security.yaml, including altering token timeout and RBAC mode settings
Because the master coordinates the entire fleet, compromising it can cascade into disabled monitoring, manipulated worker nodes, and long-term persistence via planted credentials.
The CVSS v3.1 vector AV:A/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H reflects an adjacent-network attack requiring low complexity but high privileges (possession of the cluster key), with no user interaction needed and full compromise of confidentiality, integrity, and availability.
Notably, the “Scope: Changed” designation underscores that a compromised cluster peer can affect security scope beyond its own boundary directly hitting the master.
Organizations running Wazuh 4.0.0 through 4.14.4 should prioritize upgrading to 4.14.5 or later immediately. Until patched, tightly restrict network access to cluster ports (default 1516) and rotate cluster shared keys, especially in multi-tenant or partially trusted node environments.
About the Author
