CVE-2026-25769: 
Wazuh Agent vulnerability analysis and mitigation

CVE-2026-25769 is a Remote Code Execution (RCE) vulnerability in Wazuh caused by insecure deserialization of untrusted data (CWE-502) in the cluster communication subsystem. It affects Wazuh versions 4.0.0 through 4.14.2 running in cluster mode (master/worker architecture). An attacker with access to a compromised worker node can achieve full RCE on the master node with root privileges. The vulnerability was published on March 17, 2026, and fixed in version 4.14.3. It carries a CVSS v3.1 base score of 9.1 (Critical) (Wazuh Advisory).

The vulnerability resides in framework/wazuh/core/cluster/common.py within the as_wazuh_object() function (lines 1830–1866), which is used as an object_hook in json.loads() to deserialize cluster messages. When a message contains the __callable__ key, the function reads __module__ from attacker-controlled input, calls import_module() without any whitelist validation, and then retrieves and returns an arbitrary function via getattr(). This returned function is subsequently executed in framework/wazuh/core/cluster/dapi/dapi.py (line 248) via f(**f_kwargs), allowing an attacker to invoke, for example, subprocess.getoutput with arbitrary command arguments. The attack is feasible because the master node implicitly trusts all messages from authenticated workers, and the cluster communication is encrypted with a shared Fernet key — meaning a compromised worker already possesses the necessary credentials to send malicious DAPI requests over TCP port 1516 (Wazuh Advisory).

Successful exploitation grants an attacker root-level code execution on the Wazuh master node, resulting in complete compromise of the security monitoring infrastructure. Confidentiality impact is high — all security logs, agent telemetry, and sensitive configuration data are exposed. Integrity impact is high — an attacker can silently modify detection rules, suppress alerts, and tamper with audit trails, effectively blinding the organization's security operations. Availability impact is high — the attacker can crash the cluster, delete logs, or disable monitoring entirely, with further potential to pivot to production systems via Wazuh agent command channels (Wazuh Advisory, Resecurity Blog).

Multiple high-confidence public proof-of-concept exploits are available. The primary PoC by HakaiOffsec (hakaioffsec/CVE-2026-25769 on GitHub) is a runnable Python script (poc.py) with a Docker Compose environment that demonstrates RCE against a real Wazuh cluster, confirmed to execute commands as uid=999(wazuh) gid=999(wazuh) groups=999(wazuh),0(root) on the master node (HakaiOffsec PoC). Additional PoC repositories exist (e.g., Samres27/CVE-2026-25769---CVE-2026-25770, njeru-codes/CVE-2026-25769), and the vulnerability has been incorporated into a TryHackMe training room, indicating broad community awareness. Exploitation has been reported in the wild according to Greenbone's March 2026 threat report (Greenbone Report). The EPSS score is approximately 0.0024, and no CISA KEV listing was identified in the available data. Nessus detection plugin 303595 is available (Tenable).

1. Gain access to a worker node: Obtain access to any Wazuh worker node through initial access techniques (e.g., credential theft, supply chain compromise, insider threat, or exploitation of another vulnerability on the worker host).
2. Confirm cluster connectivity: Verify the worker is connected to the master by running /var/ossec/bin/cluster_control -l on the worker, confirming the master is reachable on TCP port 1516.
3. Craft the malicious payload: Construct a JSON payload containing the __callable__ key pointing to subprocess.getoutput with the desired OS command:

{
  "f": {"__callable__": {"__name__": "getoutput", "__module__": "subprocess", "__qualname__": "getoutput"}},
  "f_kwargs": {"cmd": "id > /tmp/RCE_PROOF"},
  "request_type": "local_master"
}

4. Send the payload via LocalClient: From the worker node, use Wazuh's LocalClient.execute() API to send the malicious DAPI request to the master over the encrypted cluster channel (Fernet-encrypted TCP to master:1516):

await lc.execute(command=b'dapi', data=json.dumps(PAYLOAD).encode())

5. Trigger deserialization on master: The master's APIRequestQueue.run() receives the message and calls json.loads(request, object_hook=c_common.as_wazuh_object), which processes the __callable__ key, imports subprocess, and returns subprocess.getoutput.
6. Achieve RCE: DistributedAPI.run_local() executes f(**f_kwargs) → subprocess.getoutput(cmd='...'), running the attacker's command on the master with root privileges.
7. Verify and persist: Confirm execution (e.g., cat /tmp/RCE_PROOF), then deploy a reverse shell, exfiltrate data, or modify Wazuh rules to suppress detection (Wazuh Advisory, HakaiOffsec PoC).

• Network: Unexpected or anomalous DAPI requests originating from worker nodes to the master on TCP port 1516; unusual outbound connections from the master node to external IPs (reverse shell activity).
• File System: Presence of unexpected files in /tmp/ on the master node (e.g., /tmp/RCE_PROOF or similar attacker-created artifacts); new or modified files in /var/ossec/ directories (rules, configurations); web shells or backdoors dropped by the attacker.
• Logs: Wazuh cluster logs (/var/ossec/logs/cluster.log) showing unusual DAPI request patterns or deserialization errors; OS-level audit logs recording unexpected import_module calls or subprocess invocations by the wazuh process.
• Process: Unexpected child processes spawned by the Wazuh manager process (e.g., /bin/bash, curl, wget, python3, nc) visible via ps aux or process auditing tools; unusual subprocess.getoutput or shell command execution attributed to the wazuh user.
• Wazuh Rules/Config: Unexplained modifications to detection rules, alert thresholds, or agent configurations that could indicate an attacker suppressing monitoring (Wazuh Advisory, Resecurity Blog).

The primary remediation is to upgrade Wazuh to version 4.14.3 or later, which fixes the insecure deserialization in as_wazuh_object() by adding module whitelist validation (Wazuh Advisory). For organizations unable to patch immediately, the following interim controls are recommended:

• Isolate worker nodes: Restrict network access to worker nodes so only trusted, authorized systems can reach them; prevent untrusted external access to the cluster network.
• Strict access controls: Limit who can log into or execute code on worker nodes; enforce MFA and least-privilege principles.
• Monitor cluster traffic: Audit DAPI requests and cluster communication logs for anomalous patterns.
• Review access logs: Inspect worker node access logs for signs of unauthorized access that could indicate prior compromise (Resecurity Blog).

The vulnerability received significant attention across the security community shortly after disclosure. Resecurity published a detailed technical analysis highlighting the real-world risk to security operations centers relying on Wazuh (Resecurity Blog). Greenbone included it in their March 2026 threat report as one of the critical new enterprise risks (Greenbone Report). The Hacker News weekly recap and Security Affairs newsletter both covered the vulnerability, amplifying awareness. TryHackMe created a dedicated training room for CVE-2026-25769, generating community discussion on Reddit and Medium, with multiple walkthrough write-ups published by practitioners (Reddit). The Western Australian Government SOC also issued an advisory urging immediate patching (WA Gov SOC).