CVE-2026-25769: Wazuh Critical RCE via Insecure Deserialization in Cluster Protocol

CVE-2026-25769: Wazuh Critical RCE via Insecure Deserialization

A critical remote code execution (RCE) vulnerability has been disclosed in Wazuh, the widely deployed open-source security information and event management (SIEM) and XDR platform. Tracked as CVE-2026-25769 (CVSS 9.1, Critical), the flaw affects all Wazuh cluster deployments running versions 4.0.0 through 4.14.2 and stems from insecure deserialization of attacker-controlled data in the inter-cluster communication protocol.

The vulnerability was patched in Wazuh 4.14.3, released March 17, 2026. Mirai botnet variants have been observed targeting related Wazuh deserialization flaws, and organizations running exposed Wazuh clusters should treat this as an emergency.

Vulnerability Overview

Technical Analysis

Vulnerable Code Path

The vulnerability resides in framework/wazuh/core/cluster/common.py within the as_wazuh_object() function. This function acts as the object_hook callback in json.loads() calls used to deserialize inter-cluster messages flowing between Wazuh worker and master nodes.

When a deserialized JSON object contains a __callable__ key, the function performs the following sequence without any whitelist validation:

1. Reads __module__ directly from attacker-controlled cluster message data
2. Calls import_module() on any arbitrary module name supplied
3. Retrieves an arbitrary attribute (function) via getattr()
4. Returns the callable — which is subsequently invoked by the cluster framework

The lack of a module allowlist means any importable Python standard library or installed package can be targeted, enabling arbitrary code execution with the process's effective privileges.

Exploit Chain

1. Attacker achieves code execution on a Wazuh worker node
   (via phishing, CVE chain, or insider threat)
 
2. Crafts a malicious cluster sync message containing:
   a __callable__ key pointing to an arbitrary Python callable
   with attacker-controlled arguments
 
3. Sends the crafted message to the master node via cluster protocol (port 1516)
 
4. Master node's as_wazuh_object() deserializes the message,
   imports the attacker-specified module, and retrieves the function
 
5. The cluster framework invokes the returned callable
 
6. Arbitrary code executes with the privileges of wazuh-clusterd
   (typically root or a highly privileged service account)
 
7. Attacker achieves full root RCE on the Wazuh master node

Affected Deployments

This vulnerability only affects Wazuh deployments running in cluster mode (master/worker architecture). Standalone single-node deployments are not directly vulnerable to the remote vector described above.

Organizations at elevated risk include:

• Enterprises running multi-node Wazuh clusters for high availability
• MSSPs managing distributed Wazuh infrastructure across client environments
• SOC environments where Wazuh master nodes aggregate data from multiple worker nodes across network segments

The Wazuh ecosystem is widely deployed globally, with hundreds of thousands of active cluster installations. The master node typically holds all aggregated security event data — making RCE on the master a high-impact compromise.

Impact Assessment

Remediation

Primary Fix: Upgrade to Wazuh 4.14.3

# Upgrade Wazuh manager (all nodes — workers first, then master)
apt-get update && apt-get install wazuh-manager=4.14.3-*
# or
yum update wazuh-manager-4.14.3
 
# Restart the cluster daemon after upgrading
systemctl restart wazuh-manager
 
# Verify version
/var/ossec/bin/wazuh-control info | grep -i version

Upgrade worker nodes before the master to prevent version mismatch issues during cluster sync protocol negotiation.

Network Segmentation (Immediate Mitigation)

If immediate patching is not possible, restrict access to cluster communication port 1516/TCP to only trusted Wazuh cluster members via firewall rules. No untrusted systems should be able to reach the cluster inter-node communication port.

Detection

Monitor for suspicious process spawning from the wazuh-clusterd service, especially unexpected child processes or outbound network connections:

# Review recent wazuh-clusterd logs for errors or anomalies
journalctl -u wazuh-manager --since "24 hours ago" | grep -i "cluster\|error\|exception"
 
# Check active network connections on the cluster port
ss -tlnp | grep 1516
netstat -anp | grep 1516

Unexpected network connections originating from the Wazuh master on unusual outbound ports should be investigated as potential post-exploitation indicators.

Key Takeaways

1. CVE-2026-25769 allows an attacker controlling a Wazuh worker node to execute arbitrary code as root on the cluster master via insecure deserialization in as_wazuh_object() — no module whitelist is enforced
2. CVSS 9.1 (Critical) — network-reachable, no user interaction required, scope change to master from compromised worker
3. Mirai botnet campaigns have been observed targeting related Wazuh deserialization vulnerabilities — active exploitation is a near-certainty for exposed deployments
4. Only cluster mode deployments are affected (versions 4.0.0–4.14.2); standalone nodes face the same risk if a cluster worker is compromised
5. Patch immediately to Wazuh 4.14.3 — or isolate cluster port 1516 as an emergency measure
6. Post-compromise of a SIEM platform is an attacker's ideal position — full visibility into your security posture with no detection

Sources

• CVE-2026-25769 — NIST NVD
• GHSA-3gm7-962f-fxw5 — Wazuh RCE via Insecure Deserialization (GitHub Advisory)
• CVE-2026-25769: RCE via Insecure Deserialization in Wazuh Cluster — Hakai Security
• Wazuh RCE via Deserialization of Untrusted Data — TheHackerWire
• CVE-2026-25769 — CIRCL Vulnerability Lookup
• Exploitation of Critical Wazuh RCE Leading to Mirai Deployment — GBHackers