Description

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.4.0 through 4.14.6, a party holding the cluster key can write, overwrite, or delete arbitrary files under /var/ossec on worker nodes, leading to remote code execution as root. During cluster file synchronization, the non-merged branch of update_master_files_in_worker() moves each staged file to a destination derived only from safe_join(), which confines the path to /var/ossec but never verifies that the file lands in the directory declared by its cluster_item_key. Because the destination check present on the primary node and on the worker's merged branch was not applied, a peer can place files at attacker-chosen locations under /var/ossec, including paths that are executed as root, and the delete branch has the same gap. This is an incomplete fix for CVE-2026-30893, which addressed traversal outside /var/ossec but left this path able to redirect files anywhere within it. This issue is fixed in version 4.14.7.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-08-28T02:16:21.767Z",
  "pubdate": "2026-08-28T02:16:21.767Z",
  "executiveSummary": "Wazuh versions 4.4.0 through 4.14.6 are susceptible to an arbitrary file write vulnerability that facilitates remote code execution (RCE) with root privileges on worker nodes. The vulnerability stems from an incomplete mitigation of a previous security defect, specifically regarding insufficient path validation during cluster file synchronization.\nA remote attacker possessing a valid cluster key can manipulate the file synchronization process to overwrite, create, or delete arbitrary files within the /var/ossec directory. Because the application fails to verify that transferred files adhere to the intended destination directory defined by the cluster_item_key, an attacker can bypass security constraints to place malicious payloads in sensitive execution paths.\nThis vulnerability effectively elevates an attacker's control over the Wazuh cluster to full administrative access on affected worker nodes. The risk profile is critical, as it bypasses intended path confinement logic. Successful exploitation requires knowledge of the cluster key, which functions as an authentication credential for cluster communication. Organizations must upgrade to version 4.14.7 or higher to rectify this logic error and prevent unauthorized file system modification.",
  "technicalDetails": "The root cause of this vulnerability lies in an incomplete fix for CVE-2026-30893, specifically residing within the update_master_files_in_worker() function during cluster file synchronization operations. While previous patches addressed directory traversal attempts leading outside of the /var/ossec directory, the current implementation fails to validate that a synchronized file is actually destined for the directory explicitly declared by its associated cluster_item_key.\nThe synchronization logic utilizes the safe_join() function to resolve paths; however, this function only ensures that the final path remains within the base /var/ossec directory. It does not perform an integrity check to verify that the file's target location corresponds to the directory expected for that specific item type. Consequently, the mechanism responsible for moving staged files to their destination is vulnerable to path redirection.\nAn attacker holding the cluster key can initiate a malicious cluster synchronization process. By crafting a payload where the target file destination is manipulated, the attacker leverages the lack of destination verification to write files to arbitrary locations within the /var/ossec hierarchy. This includes critical binary directories, configuration files, or scripts that are automatically executed by the Wazuh daemon or associated services running with root privileges.\nThe attack flow follows these steps: 1) The attacker authenticates using a compromised cluster key. 2) The attacker sends a synchronization request or triggers a synchronization event containing a malicious file payload. 3) The worker node receives the file, and the update_master_files_in_worker() function processes the file move operation. 4) Due to the lack of destination validation, the file is written to an attacker-chosen path such as a plugin or binary directory. 5) Upon the next execution cycle or service restart, the malicious file is executed by the system, granting the attacker arbitrary code execution with root-level permissions.\nThis vulnerability affects both the file write/overwrite and the file delete branches of the synchronization logic. Because the validation check is applied on the primary node and the merged branch of the worker, but is notably absent in the non-merged branch of the worker's file synchronization process, the system remains exposed to malicious updates. The impact is significant, as it permits persistent access and full system compromise on any worker node in the cluster."
}