CVE-2026-61800

Wazuh versions 4.4.0 through 4.14.6 contain a path-verification gap in the worker side of cluster file synchronization: in the non-merged branch of update_master_files_in_worker(), received files are moved to a destination derived only from safe_join(), which confines the path to /var/ossec but never checks that the file lands in the directory declared by its cluster_item_key, and the delete branch has the same gap. As a result, any party holding the cluster key can write, overwrite, or delete arbitrary files anywhere under /var/ossec on worker nodes, including locations whose contents are executed as root. Successful exploitation therefore yields remote code execution as root on affected worker nodes, with the high-privilege prerequisite reflected in the CVSS score of 9.1 (PR:H, scope changed). Only Wazuh deployments running cluster mode with worker nodes on the affected versions are exposed, and this is an incomplete fix for CVE-2026-30893, which blocked traversal outside /var/ossec but left redirection within it possible. No public proof-of-concept or confirmed in-the-wild exploitation is known; EPSS estimates roughly a 0.6% probability of exploitation within 30 days and the issue is not in CISA KEV.

What to do: Upgrade Wazuh servers/managers to version 4.14.7 or later, which is required even if you already deployed the fix for CVE-2026-30893, since that earlier patch left this gap open. Until upgrading, restrict access to the Wazuh cluster communication service (default TCP 1516) to trusted hosts, rotate the cluster key if its exposure is suspected, and audit /var/ossec on worker nodes for unexpected new, modified, or deleted files — especially in paths executed as root. Any host that held the cluster key should be treated as a potential source of root-level compromise on its worker peers.