CVE-2026-28220 is a deserialization flaw in the Wazuh Cluster Distributed API. A cluster peer, or anyone who can authenticate with the shared cluster key, can make the master node run an attacker chosen function with attacker chosen permissions. NVD scores it 8.4. Upgrade to Wazuh 4.14.5 or later.
What's affected
The GitHub advisory GHSA-w2jj-pfq9-mh9p, published 16 July 2026, lists affected versions as 4.0.0 and later and patched versions as 4.14.5 and later. NVD's description says the same thing in different words: versions prior to 4.14.5.
The advisory bundles two issues that amplify each other.
- Unsafe callable deserialization. Cluster code rebuilds JSON into live functions, and the only check is that the function's top-level package is wazuh or api. That allow list is broad.
- Injected authorization context. Distributed API requests may carry their own permission settings, and the master applies them as the global context for the call instead of deriving them from a verified identity.
The precondition matters. The attacker must be a cluster peer, or hold the shared cluster key and be able to reach the master's cluster channel. NVD's vector reflects that: adjacent network, high privileges required, scope changed, giving 8.4.
The advisory states that the demonstrated impact includes arbitrary file writes under the Wazuh install path, creation of new API users, and tampering with the security configuration, and that these can be chained into full manager compromise.
How to check if you're exposed
Find every Wazuh manager and note the version. On a manager host, the control script reports it.
/var/ossec/bin/wazuh-control info
Any 4.x version below 4.14.5 is in scope.
Then review who and what can reach the cluster channel. The advisory's test environment used the default cluster port, 1516. Check your firewall rules and security groups for that port, and list which hosts can connect to it. Anything that is not another Wazuh cluster node should not be able to.
Finally, find where the shared cluster key is stored. It is a credential, so check who has read access to the configuration that holds it.
What to do now
- Upgrade all Wazuh manager nodes to 4.14.5 or later, workers and master alike, following Wazuh's documented upgrade order for clusters.
- Restrict the cluster port to the addresses of your own cluster nodes with host and network firewalls.
- Rotate the shared cluster key after upgrading if you have any doubt about who has seen it, and update it on every node.
- Review the master for unexpected API users, changes to the security configuration, and files written under the Wazuh directory.
- Treat the Wazuh manager as a high value asset in your own inventory. It holds the visibility you rely on to catch other incidents.
Why it matters
The primary weakness is CWE-502 (Deserialization of Untrusted Data). The cluster protocol lets a node send a request that names a function to run. A safe design uses a fixed table of permitted functions. This code resolved any callable in two top-level packages, which turns choosing a function into attacker input.
The second weakness, CWE-863 (Incorrect Authorization), is that the permission mode came along with the request. Authorization works only when the server decides what a caller may do. If the caller supplies the answer, the check passes whenever the caller wants it to.
Together they make a point that applies beyond Wazuh. Internal channels between trusted nodes are still attack surface, because a single stolen key or one compromised node becomes a route to the node with the most privilege. Security tools get this treatment less often than they should, and a compromised manager is a particularly bad outcome.
The record does not flag exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog. The practical risk depends on whether an adversary can reach the cluster channel with the key, which is something you control with network rules and key handling.
Quick check
Do I need to worry if I run a single Wazuh node, not a cluster?
The advisory describes the cluster channel and its shared key, so single-node setups without that exposure are less directly in scope. Upgrading to 4.14.5 is still the recommended fix, and it is a normal maintenance step.
What is the first thing to lock down?
Network access to the cluster port, so only your cluster nodes can connect, and tight handling of the shared cluster key. Then upgrade to 4.14.5.
Is this exploitable by anyone on the internet?
Not by the description. The attacker needs to authenticate to the cluster channel with the shared key. NVD scores it with adjacent network access and high privileges required.
Sources
Last reviewed: 19 October 2026.
