EUVD-2026-62557Severity by source
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Attacker must hold the shared cluster key so PR:H; the traversal breaks out of the cluster directory to root-owned config yielding scope change and full host compromise, so S:C and C/I/A:H.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
4DescriptionCVE.org
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.
AnalysisAI
Path-traversal-driven root code execution affects the Wazuh security platform's cluster synchronization layer in versions 4.0.0 through 4.14.5 and the 5.0.0-beta line up to 5.0.0-beta3. A malicious or compromised cluster peer that possesses the shared Fernet key can smuggle directory-traversal sequences through merge_type/name values or a merged-file header, causing the master node to write attacker-controlled files (e.g. /var/ossec/etc/ossec.conf) outside the intended cluster item directory; overwriting ossec.conf lets the attacker define root-executed commands that fire when Wazuh services reload. No public exploit has been identified at time of analysis, and the issue is not in CISA KEV; the vendor fix landed in 4.14.6 and 5.0.0-beta3.
Technical ContextAI
Wazuh clusters synchronize state between master and worker nodes by shipping merged synchronization archives whose contents are described in files_metadata.json plus per-file headers embedded in the merged blob. cluster.unmerge_info() in framework/wazuh/core/cluster/cluster.py rebuilt destination paths directly from peer-supplied merge_type and name fields, and process_files_from_worker() in framework/wazuh/core/cluster/master.py failed to confine the reconstructed path to the declared cluster item directory - a textbook CWE-22 improper limitation of a pathname to a restricted directory. Because the CPE scopes this to cpe:2.3:a:wazuh:wazuh:*, every affected release of the application is in range. The fix (PR #36204, commit 88fc89f) adds character validation rejecting '/', '\' and leading-dot in merge_type/filename, basename-normalizes header names, validates item_key against the known cluster_items set, and uses safe_join plus os.path.commonpath to assert the final path stays under the expected base directory.
RemediationAI
Upgrade to a fixed release: Vendor-released patch: Wazuh 4.14.6 for the 4.x line, or 5.0.0-beta3 for the 5.0 beta line (see GHSA-gh4h-fx78-q8xc, PR https://github.com/wazuh/wazuh/pull/36204, commit 88fc89fdfb1bf37b9d826e9c281a3d22655733de). Where immediate patching is not possible, reduce the attack surface by tightly controlling cluster membership: rotate the shared cluster Fernet key and restrict who and what can obtain it, network-segment the cluster communication port (1516) so only trusted, known node IPs can reach the master, and treat any worker node as a potential path to the master. Monitor for unexpected modifications to /var/ossec/etc/ossec.conf and to files written outside declared cluster item directories, and alert on Wazuh service reloads that follow config changes. These controls limit exposure but do not close the traversal itself - only the patch adds the path-confinement checks - and aggressive network restriction can disrupt legitimate cluster sync if node inventories change, so validate node allow-lists before enforcing.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
In the wazuh-slack active response script in Wazuh 4.2.x before 4.2.5, untrusted user agents are passed to a curl comman
Arbitrary file read in Wazuh cluster deployments (4.0.0 through 4.14.5, and 5.0.0-beta1/beta2) lets a peer node that alr
Arbitrary file write leading to root remote code execution affects Wazuh worker nodes in clustered deployments running v
A critical deserialization vulnerability in Wazuh's cluster mode allows attackers with access to any worker node to achi
Remote code execution on the Wazuh cluster master node is achievable by any attacker who controls a cluster worker node,
Path traversal in Wazuh's ip-customblock active response script allows low-privileged remote attackers to create or dele
The agent in OSSEC through 3.1.0 on Windows allows local users to gain NT AUTHORITY\SYSTEM access via Directory Traversa
Cluster key disclosure in Wazuh Manager versions 4.0.0 through 4.14.4 enables a two-stage privilege escalation: a low-pr
Unauthenticated remote denial of service in the Wazuh cluster daemon (wazuh-clusterd) allows a network peer to exhaust p
Arbitrary file deletion on a Wazuh manager via the cluster synchronization protocol allows a cluster-authenticated attac
CVE-2024-1243 is an improper input validation vulnerability in Wazuh agent for Windows (versions prior to 4.8.0) that al
Same weakness CWE-22 – Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today