CVE-2026-25769 Analysis: Remote Code Execution in Wazuh Cluster via Insecure Deserialization

1. Introduction – Executive Summary

Security monitoring platforms are among the most privileged systems on a corporate network: they collect logs from every endpoint, monitor file integrity, and — when needed — push commands back down to those endpoints. Compromising such a platform therefore carries consequences far beyond the loss of a single server.

CVE-2026-25769 enables exactly that scenario. In Wazuh’s cluster architecture, the JSON deserialization mechanism used on the DAPI communication channel between Worker nodes and the Master node allows arbitrary Python modules to be imported without any validation of the incoming data. As a result, an attacker who gains access to a single Worker node can execute code remotely on the Master node.

This article examines the technical root cause, the attack surface, the prerequisites, the organizational impact, and the defensive measures available.

All analysis was performed exclusively in an isolated laboratory environment, on authorized systems, for educational and research purposes.

Field	Value
CVE ID	CVE-2026-25769
Affected Product	Wazuh (Server / Manager)
Affected Versions	4.0.0 – 4.14.2
Vulnerability Type	Remote Code Execution (RCE)
CWE	CWE-502: Deserialization of Untrusted Data
CVSS Score	9.1 / Critical — CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Impact	Confidentiality (High), Integrity (High), Availability (High)
Publication Date	17 March 2026
Patch Status	Fixed in version 4.14.3

2. Legal Notice

Legal Notice: This article was prepared solely for cybersecurity awareness, defense, vulnerability management, and educational purposes. The technical information discussed here must only be tested in authorized and isolated laboratory environments. Vulnerability scanning, exploitation attempts, unauthorized access, or any action that may cause service disruption on systems you do not own or have permission to test may result in civil and criminal liability.

Within the Republic of Türkiye, unauthorized access, interference, data destruction, data modification, or denial of service against information systems may be prosecuted under Turkish Criminal Code No. 5237 and related legislation. This work does not target any system and does not encourage misuse.

Implementation Note: All testing described in this article was performed in an air-gapped, isolated, and controlled lab environment. It must not be reproduced on production systems.

3. Terminology

Term	Description
CVE	Common Vulnerabilities and Exposures – the standard identification system for security vulnerabilities.
CVSS	Common Vulnerability Scoring System – the system used to score the technical severity of vulnerabilities.
CWE	Common Weakness Enumeration – the reference taxonomy classifying software and hardware weaknesses.
RCE	Remote Code Execution.
SIEM / XDR	Platform architectures where security events are centrally collected and correlated, and responses are executed on endpoints.
Deserialization	The process of converting serialized (text/byte) data back into programmatic objects.
object_hook	A callback passed to Python’s json.loads() that is invoked for every JSON object parsed.
DAPI	Distributed API – the Wazuh component that carries inter-node API requests within a cluster.
Master / Worker Node	In Wazuh cluster architecture, the central analysis node and the auxiliary data-collecting nodes respectively.
Fernet	A symmetric encryption scheme in Python’s cryptography library based on a shared key.
Allowlist	A security control that accepts only explicitly permitted values.
PoC	Proof of Concept – a controlled demonstration that a vulnerability exists.
Mitigation	A temporary or permanent measure that reduces the impact of a vulnerability.

4. Vulnerability Identification

Field	Value
CVE ID	CVE-2026-25769
GHSA ID	GHSA-3gm7-962f-fxw5
Product / Component	Wazuh Server – cluster communication layer (framework/wazuh/core/cluster/common.py, dapi/dapi.py)
Vendor	Wazuh Inc.
Affected Versions	>= 4.0.0, < 4.14.3 (4.0.0 – 4.14.2)
Fixed Version	4.14.3
Vulnerability Type	Remote Code Execution (Insecure Deserialization)
CWE	CWE-502: Deserialization of Untrusted Data
CVSS v3.1 Score	9.1 / Critical
CVSS Vector	CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Attack Vector	Network (TCP 1516 – cluster port)
Attack Complexity	Low
Privileges Required	High (requires a valid cluster key / access to a Worker node)
User Interaction	None
Scope	Changed – the vulnerable component affects resources beyond its own security boundary
Publication Date	17 March 2026 (NVD)
Credits	Texuguinho1234 (reporter), skraft9 (finder)
Sources	NVD, GitHub Security Advisory, Wazuh CTI

5. Affected Systems and Versions

This vulnerability applies only to Wazuh deployments running in cluster mode. Standalone single-server installations have no Master–Worker communication channel and therefore no exploitable surface.

• Affected: Wazuh 4.0.0 – 4.14.2 with cluster mode enabled (<cluster><disabled>no</disabled></cluster>)
• Not affected: 4.14.3 and later; standalone installations with cluster mode disabled
• CPE: cpe:2.3:a:wazuh:wazuh:*:*:*:*:*:*:*:* — from 4.0.0 (inclusive) up to 4.14.3 (exclusive)

To verify your installed version:

/var/ossec/bin/wazuh-control info
cat /var/ossec/etc/ossec.conf | grep -A5 "<cluster>"

6. Background

Wazuh is an open-source security platform used in enterprise networks for threat prevention, detection, and response (SIEM/XDR). It collects logs from systems, monitors file integrity (FIM), performs vulnerability scanning, and generates alerts on detected anomalies.

In large, distributed environments Wazuh runs as a cluster of Master and Worker nodes rather than a single server. Worker nodes report the security logs, alerts, and agent status information gathered from endpoints to the Master node, which holds the central rule set, analysis engine, and database.

The communication flow works as follows:

1. The Worker node serializes the data it is forwarding into JSON.
2. The packet is encrypted with the symmetric Fernet key shared between nodes.
3. The encrypted packet is sent to the Master node over TCP port 1516.
4. The Master decrypts it and converts the data back into Python objects using json.loads().
5. The resulting data is evaluated against the central security rules.

The vulnerability arises in step 4. When parsing the JSON, the Master node passes as_wazuh_object() as the object_hook parameter. The architecture’s underlying assumption is this: any packet that can be successfully decrypted with the Fernet key is trustworthy. Because of that assumption, no content validation is performed on the decrypted data.

7. Technical Root Cause Analysis

The vulnerability resides in the as_wazuh_object() function in framework/wazuh/core/cluster/common.py (lines 1830-1866). When the function encounters a __callable__ key in the JSON, it performs the following steps:

1. Reads the user-controlled __module__ value.
2. Imports it via import_module() without any allowlist validation.
3. Retrieves the requested function from the module using getattr().
4. Returns the function object — which is subsequently invoked.

The execution point is in framework/wazuh/core/cluster/dapi/dapi.py: the function deserialized by json.loads(request, object_hook=c_common.as_wazuh_object) is later called with its arguments as f(**f_kwargs) inside DistributedAPI.run_local().

In other words, a mechanism designed purely for reading data can be turned into operating-system-level command execution. The chain breaks at three points:

• Implicit trust: The Master accepts any authenticated Worker message without question.
• No allowlist: The modules that may be loaded during deserialization are not restricted.
• Unvalidated execution: The deserialized callable is invoked without any additional type or authorization check.

8. Attack Surface and Prerequisites

The primary attack surface is TCP port 1516, on which the Master node listens for cluster communication. The DAPI module served over this port is the entry point that accepts JSON data from Worker nodes.

Two prerequisites must be met for practical exploitation:

1. Network access. The attacker must be able to send packets to the Master node’s TCP 1516 port. If the port is restricted by firewall rules to known Worker IP addresses, direct external attack is not possible and the attack must originate from a Worker node.

2. A valid cluster key. For the packet to be accepted and decrypted by the Master, the attacker must possess the symmetric Fernet key shared between nodes. This key is stored in the <cluster><key> field of ossec.conf.

This second condition is the reason for the PR:H (high privileges required) value in the CVSS vector. In practice, however, the key is stored in plaintext on every Worker node, which means compromising a single Worker is equivalent to compromising the entire cluster. That is precisely why the vulnerability is rated critical: it converts a lateral foothold directly into a central collapse.

9. Impact Analysis

Because the Master node runs with elevated privileges, successful exploitation means the complete compromise of the organization’s security infrastructure.

Confidentiality. Security logs collected from every device on the network, agent data, Active Directory configurations, and sensitive configuration files are exposed. A central security platform is, by definition, where an organization’s most sensitive data accumulates.

Integrity. The attacker can delete or modify historical logs to hide their tracks, disable central detection rules, allowlist their own infrastructure, or generate false alerts to misdirect the SOC team. This is the most dangerous scenario: the attack continues while the defensive side sees nothing.

Availability. The Master server can be crashed, the database wiped, or the system encrypted with ransomware.

Propagation. Wazuh’s Active Response feature allows the Master to execute commands on endpoint devices. An attacker controlling the Master can abuse this central authority to distribute malicious code simultaneously to every connected endpoint. For this reason the vulnerability must be treated not as an isolated server problem but as a cascading enterprise risk.

The S:C (Scope: Changed) value in the CVSS vector expresses exactly this: the vulnerable component can affect resources beyond its own security boundary.

10. Lab Environment

Verification was performed in an air-gapped, isolated laboratory setup.

• Virtualization: Docker / Docker Compose
• Target System: Wazuh Manager (Master node in cluster mode)
• Vulnerable Application: Wazuh 4.x (pre-4.14.3 release)
• Attacker/Test Machine: Worker node container on the same isolated network
• Network Topology: Isolated bridge network, no external connectivity
• Internet Access: Disabled
• Logging: Enabled
• Snapshot: Taken; environment reset after testing

11. Verification

Cluster Configuration

The Master node configuration (master.xml) defines the cluster name, node type, shared key, and bind address.

The Worker configuration (worker.xml) is largely identical; only node_type is set to worker and node_name to worker01. Both nodes share the same key value — and that shared key is what authenticates the Worker to the Master.

Payload Structure

For verification, a JSON object is constructed that triggers Wazuh’s deserialization mechanism. The __callable__ key is set to point at a function in Python’s subprocess module, the arguments to be executed are placed in f_kwargs, and request_type is set to local_master so that the request is processed directly on the Master.

Verification Script

The script uses load_module() to dynamically import Wazuh’s LocalClient class from the framework directory, which avoids Python import path issues inside the container. It then instantiates LocalClient, connects to the local cluster socket, and delivers the payload via the dapi command.

The script forwards the prepared payload to the Master node over the encrypted cluster channel. When the Master decrypts and deserializes the packet, the specified function executes on the Master, confirming command execution.

PoC Note: This section shares only benign, verification-oriented output produced in an isolated laboratory environment. Full exploit code, ready-to-use payloads, and automation details that could enable misuse against production systems have been deliberately withheld. The complete technical detail is publicly available in the vendor’s official advisory.

12. Detection and Log Analysis

Because exploitation occurs inside the encrypted cluster channel, network-level content inspection is unlikely to catch it. Detection efforts should therefore focus on behavior observed on the Master node.

Process telemetry

• Unexpected child processes spawned under wazuh-clusterd — particularly sh, bash, curl, wget, nc, or python
• subprocess-originated command execution on the Master outside normal workflow
• Unexpected outbound network connections in the context of the Wazuh service account

Cluster and DAPI logs

• Unusual DAPI request types or a rise in exception volume in /var/ossec/logs/cluster.log
• A sudden, unexplained increase in request_type: local_master requests
• Cluster connection attempts from unexpected node names

Network level

• Connections to TCP 1516 from outside the known Worker IP list
• Abnormal packet sizes in cluster traffic

Integrity monitoring

• Unexpected changes to /var/ossec/etc/ossec.conf, rule files, or Active Response configuration
• New executable files appearing in /tmp and similar directories on the Master
• Signs of retroactive deletion or truncation in log files

If exploitation is suspected, remember that alerts produced by the Master node can no longer be trusted; verification must be performed through an independent telemetry source outside Wazuh.

13. Mitigation and Remediation

Permanent Fix

• Upgrade Wazuh to version 4.14.3 or later. The fix introduces an allowlist that blocks arbitrary module imports during deserialization.
• Audit and restrict which users and processes may interact with LocalClient.

Temporary Measures (if patching is not possible)

• Restrict network access. Permit connections to TCP 1516 only from known Worker IP addresses, and confirm the port is not exposed to the internet.
• Apply network segmentation. Keep Master and Worker nodes in a separate, tightly controlled segment.
• Monitor Worker node integrity. Since the first link in the chain is a compromised Worker, anomalies there serve as early warning.
• Rotate cluster keys. Refresh the <cluster><key> value periodically and after any suspected incident.
• Harden key file permissions. Prevent unnecessary accounts from reading ossec.conf.

Post-Patch Verification

# Version check
/var/ossec/bin/wazuh-control info

# Cluster health check
/var/ossec/bin/cluster_control -l

After upgrading, ensure that all nodes (Master and every Worker) run the same version; in a mixed-version cluster, unpatched nodes remain exposed.

14. Conclusion

CVE-2026-25769 is a critical vulnerability, classified under CWE-502, that under the right conditions leads to the complete compromise of an organization’s security infrastructure. Its root cause is the assumption that encryption on the inter-node channel substitutes for data validation — as_wazuh_object() treats content as trustworthy because it arrived from an authenticated source, and permits arbitrary module loading as a result.

The broader lesson goes beyond the technical detail: transport-layer security is not a substitute for application-layer input validation. Fernet encryption authenticates the origin of a packet; it guarantees nothing about the safety of its contents. Any component that performs deserialization must apply allowlist-based type and module restrictions regardless of how trusted the data source appears to be.

The most effective defensive posture is to apply the vendor patch quickly, narrow the attack surface through network segmentation, rotate cluster keys regularly, and monitor the Master node with independent process telemetry.

15. TL;DR

• CVE-2026-25769 is a remote code execution (RCE) vulnerability in the Wazuh cluster caused by insecure deserialization.
• Affected versions: 4.0.0 – 4.14.2 (cluster mode only). Fixed in: 4.14.3
• CVSS: 9.1 / Critical — CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H, CWE-502
• Root cause: as_wazuh_object() passes the JSON-supplied __module__ value to import_module() without allowlist validation.
• Prerequisites: access to a Worker node plus the shared Fernet cluster key. Compromising one Worker is enough to take down the whole cluster.
• Impact: code execution with elevated privileges on the Master node; log manipulation and network-wide propagation via Active Response.
• Most reliable fix: upgrade to 4.14.3. If that is not possible, restrict TCP 1516 access, apply segmentation, and rotate the cluster key.
• Testing must be confined to isolated lab environments.

16. References

• NVD – CVE-2026-25769: https://nvd.nist.gov/vuln/detail/CVE-2026-25769
• MITRE – CVE-2026-25769: https://www.cve.org/CVERecord?id=CVE-2026-25769
• GitHub Security Advisory (GHSA-3gm7-962f-fxw5): https://github.com/wazuh/wazuh/security/advisories/GHSA-3gm7-962f-fxw5
• Wazuh CTI – Vulnerability Database: https://cti.wazuh.com/vulnerabilities/cves/CVE-2026-25769
• CWE-502 – Deserialization of Untrusted Data: https://cwe.mitre.org/data/definitions/502.html
• CVSS v3.1 Calculator: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
• Tenable – Wazuh Server 4.0.0 < 4.14.3 RCE: https://www.tenable.com/plugins/nessus/303595
• Resecurity – CVE-2026-25769 analysis: https://www.resecurity.com/blog/article/cve-2026-25769-critical-remote-code-execution-in-wazuh-via-unsafe-deserialization
• TryHackMe – Wazuh: CVE-2026-25769 (hands-on lab room): https://tryhackme.com/room/wazuhcve202625769