CVE-2026-25769
Remote Code Execution via Deserialization in Wazuh Cluster
Publication date: 2026-03-17
Last updated on: 2026-03-19
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| wazuh | wazuh | From 4.0.0 (inc) to 4.14.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-502 | The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-25769 is a critical Remote Code Execution (RCE) vulnerability in Wazuh Cluster versions 4.0.0 through 4.14.2. It arises from insecure deserialization of untrusted data in the function as_wazuh_object(), which is used to deserialize JSON messages between cluster nodes.
The vulnerability occurs because the function processes JSON objects containing a __callable__ key and reads the __module__ field from user-controlled input without any validation or whitelist. This allows an attacker to specify any module and function to be imported and executed on the master node.
An attacker who has compromised a worker node can send specially crafted messages to the master node, causing it to execute arbitrary code with root privileges. This is possible because the master trusts authenticated workers and deserializes their messages using the vulnerable function.
How can this vulnerability impact me? :
This vulnerability can have severe impacts including full Remote Code Execution on the master node with root privileges if an attacker compromises a worker node.
- Confidentiality: The attacker can access all security logs, agent data, and sensitive information.
- Integrity: The attacker can modify alerts, rules, and configurations, potentially hiding malicious activity.
- Availability: The attacker can disable monitoring, delete logs, or crash the cluster, disrupting security operations.
- Privilege Escalation: Since the master runs as root, the attacker gains root-level control over the system.
Overall, this leads to complete compromise of the Wazuh monitoring infrastructure, enabling silent bypass of alerts, data exfiltration, lateral movement within the network, and loss of control over security monitoring.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for unusual or unauthorized cluster communication on TCP port 1516, which is used for master-worker communication in Wazuh clusters.'}, {'type': 'paragraph', 'content': "Since the exploit involves a malicious worker sending specially crafted DAPI requests that are encrypted with the cluster's shared Fernet key, detection can focus on identifying unexpected or suspicious commands executed on the master node, especially those originating from worker nodes."}, {'type': 'paragraph', 'content': 'Commands to check for suspicious activity might include inspecting the /tmp directory for files like /tmp/RCE_PROOF, which is used in the proof of concept to confirm code execution.'}, {'type': 'list_item', 'content': 'Check for unexpected files created by exploits, e.g., `ls -l /tmp/RCE_PROOF`'}, {'type': 'list_item', 'content': 'Monitor network connections on port 1516: `netstat -anp | grep 1516` or `ss -anp | grep 1516`'}, {'type': 'list_item', 'content': 'Review Wazuh master logs for unusual or unauthorized commands or errors related to cluster communication.'}, {'type': 'list_item', 'content': 'Audit running processes for unexpected commands executed by the master node, e.g., `ps aux | grep python` or commands invoking subprocesses.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate and most effective mitigation is to upgrade all Wazuh cluster nodes to version 4.14.3 or later, where this vulnerability is fixed.
Until the upgrade can be performed, restrict access to the cluster communication port (TCP 1516) to trusted hosts only, and monitor for any suspicious activity on worker nodes.
Ensure that worker nodes are secure and not compromised, as the vulnerability requires a compromised worker node to exploit the master.
- Upgrade Wazuh cluster to version 4.14.3 or later.
- Restrict network access to TCP port 1516 to trusted worker nodes.
- Audit and secure worker nodes to prevent initial compromise.
- Monitor master node logs and system activity for signs of exploitation.