Description

Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.0.0 until 4.14.6 and 5.0.0-beta3, cluster.unmerge_info() in framework/wazuh/core/cluster/cluster.py constructs paths from peer-controlled merge_type and name values in a merged synchronization archive. process_files_from_worker() in framework/wazuh/core/cluster/master.py does not adequately confine the resulting path to the declared cluster item directory. A cluster peer holding the shared Fernet key can use traversal in files_metadata.json or a merged-file header to write files such as /var/ossec/etc/ossec.conf. Replacing ossec.conf can configure root-executed commands and lead to code execution when Wazuh services reload. This issue is fixed in versions 4.14.6 and 5.0.0-beta3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-19T17:18:51.093Z",
  "pubdate": "2026-08-19T17:18:51.093Z",
  "executiveSummary": "A path traversal vulnerability exists in the Wazuh platform affecting versions from 4.0.0 until 4.14.6 and 5.0.0-beta3. The vulnerability stems from insecure handling of peer-controlled parameters within the cluster synchronization mechanism. Specifically, the function cluster.unmerge_info() in framework/wazuh/core/cluster/cluster.py constructs file paths using peer-controlled merge_type and name values from a merged synchronization archive, while process_files_from_worker() in framework/wazuh/core/cluster/master.py fails to adequately confine the resulting path to the declared cluster item directory.\nAn authenticated cluster peer possessing the shared Fernet key can exploit this flaw by manipulating traversal sequences within files_metadata.json or a merged-file header. This allows the attacker to write arbitrary files to the underlying system, such as replacing /var/ossec/etc/ossec.conf. Successful exploitation enables the configuration of root-executed commands, ultimately leading to arbitrary remote code execution upon the reloading of Wazuh services.\nThe risk implication is critical, as it compromises the integrity and confidentiality of the host operating system through cluster communication channels. Mitigation requires upgrading to version 4.14.6, 5.0.0-beta3, or later versions where this vulnerability is resolved.",
  "technicalDetails": "The vulnerability is localized within the clustering framework of Wazuh, specifically impacting framework/wazuh/core/cluster/cluster.py and framework/wazuh/core/cluster/master.py. The vulnerable component is responsible for handling synchronization data transmitted between cluster nodes, such as masters and workers.\nThe root cause of the vulnerability is insufficient input validation and path sanitization. The function cluster.unmerge_info() processes a merged synchronization archive containing peer-controlled merge_type and name values. These values are directly utilized to construct file system paths without verifying that the resulting path stays within the intended boundaries. Subsequently, the function process_files_from_worker() fails to adequately confine the final destination path to the declared cluster item directory.\nTo exploit this vulnerability, an attacker requires access as a cluster peer and must hold the shared Fernet key used to encrypt and decrypt cluster communications. The attacker crafts a malicious payload by injecting directory traversal sequences (such as ../) into the files_metadata.json file or into a merged-file header within the synchronization archive.\nThe step-by-step attack flow proceeds as follows: 1) The malicious cluster peer generates a synchronization payload containing traversal patterns in the metadata or headers; 2) The payload is transmitted to the master node over the cluster communication channel; 3) The master node's cluster.unmerge_info() parses the archive and constructs the target file path using the untrusted merge_type and name parameters; 4) The process_files_from_worker() function fails to restrict the path confinement, allowing the write operation to escape the designated cluster item directory; 5) The attacker writes an arbitrary file to a sensitive system location, such as /var/ossec/etc/ossec.conf; 6) Upon the subsequent reload of Wazuh services, the manipulated configuration file triggers root-executed commands, achieving arbitrary code execution on the target system."
}