CVE-2026-61800: Wazuh Security Platform RCE Vulnerability

CVE-2026-61800 Overview

CVE-2026-61800 is a path traversal vulnerability [CWE-22] in Wazuh, an open-source XDR and SIEM platform. The flaw affects versions 4.4.0 through 4.14.6 and resides in the cluster file synchronization routine on worker nodes. A peer holding the cluster key can write, overwrite, or delete arbitrary files under /var/ossec, including paths that Wazuh executes as root. Exploitation leads to remote code execution with root privileges. The issue is an incomplete fix for CVE-2026-30893, which constrained traversal outside /var/ossec but left redirection within the directory possible. Wazuh released a patch in version 4.14.7.

Critical Impact
An authenticated cluster peer can achieve root remote code execution on any worker node by placing files at attacker-chosen paths under /var/ossec.

Affected Products

Wazuh Server 4.4.0 through 4.14.6
Wazuh cluster worker nodes running the affected framework/wazuh/core/cluster/worker.py
Deployments where the Wazuh cluster key is shared between master and worker peers

Discovery Timeline

2026-08-28 - CVE-2026-61800 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-61800

Vulnerability Analysis

The vulnerability resides in the update_master_files_in_worker() function inside framework/wazuh/core/cluster/worker.py. During cluster synchronization, worker nodes receive staged files from peers and move each file to a destination path. The non-merged branch derives that destination using only safe_join(), which restricts the resulting path to /var/ossec but does not verify that the file lands in the directory associated with its declared cluster_item_key.

A peer holding the cluster pre-shared key can supply arbitrary filenames while retaining a valid cluster_item_key. The worker then writes, overwrites, or deletes files at attacker-chosen locations under /var/ossec. Because Wazuh executes several files in that tree as root, attackers can drop scripts or binaries into privileged execution paths. The delete branch contains the same gap, enabling destructive removal of critical files.

Root Cause

The destination confinement check that exists on the primary node and on the worker's merged branch was never applied to the non-merged and extra file branches. safe_join() alone confines paths to /var/ossec but does not enforce alignment between the target directory and the cluster_item_key metadata.

Attack Vector

Exploitation requires network access to the cluster synchronization channel and possession of the cluster key. Once the attacker acts as a peer, they craft synchronization payloads with arbitrary file paths under /var/ossec. The worker accepts the payload and stages files at the requested location.

python

                               ownership=(common.wazuh_uid(), common.wazuh_gid())
                               )
             else:
+                item_key = data_['cluster_item_key']
+                if item_key not in cluster_items['files']:
+                    raise WazuhClusterError(3022, extra_message=f"Invalid cluster_item_key: {item_key}")
+                expected_base = safe_join(common.WAZUH_PATH, item_key)
+                if not os.path.commonpath([full_filename_path, expected_base]).startswith(expected_base):
+                    raise WazuhClusterError(3022,
+                        extra_message=f"File path outside allowed directory: {filename_}")
                 # Create destination dir if it doesn't exist.
                 if not os.path.exists(os.path.dirname(full_filename_path)):
                     utils.mkdir_with_mode(os.path.dirname(full_filename_path))
                 # Move the file from zipdir (directory containing unzipped files) to <wazuh_path>/filename.
                 safe_move(safe_join(zip_path, filename_), full_filename_path,
-                          permissions=cluster_items['files'][data_['cluster_item_key']]['permissions'],
+                          permissions=cluster_items['files'][item_key]['permissions'],
                           ownership=(common.wazuh_uid(), common.wazuh_gid())
                           )

Source: Wazuh Security Patch Commit

The patch introduces an expected_base derived from the cluster_item_key and uses os.path.commonpath() to confirm the destination sits inside that base. Requests with mismatched paths now raise WazuhClusterError(3022).

Detection Methods for CVE-2026-61800

Indicators of Compromise

Unexpected file writes, modifications, or deletions under /var/ossec on worker nodes that do not correspond to legitimate cluster synchronization activity
Wazuh cluster logs showing file transfers where the destination path does not match the declared cluster_item_key
New or modified scripts, binaries, or configuration files in Wazuh directories that are executed by root-owned services

Detection Strategies

Monitor process execution and file integrity events under /var/ossec and correlate against cluster synchronization timestamps in cluster.log
Alert on child processes spawned by wazuh-execd or other root-owned Wazuh services that execute recently modified files
Compare file paths in cluster synchronization traffic against expected cluster_item_key mappings defined in cluster.json

Monitoring Recommendations

Enable file integrity monitoring on the entire /var/ossec tree with a focus on active-response, queue, and etc subdirectories
Capture and retain Wazuh cluster synchronization logs for post-incident review
Track authentication events for the cluster port (default 1516) to identify unauthorized peers connecting with the cluster key

How to Mitigate CVE-2026-61800

Immediate Actions Required

Upgrade all Wazuh cluster nodes to version 4.14.7 or later, ensuring master and worker versions match
Rotate the cluster key on every node and restrict network access to the cluster port to trusted management networks only
Audit /var/ossec on worker nodes for files created or modified during the exposure window and validate integrity against known-good baselines

Patch Information

The fix is available in Wazuh 4.14.7. The patch adds destination confinement by validating that the resolved file path stays within the directory declared by cluster_item_key. Review the Wazuh Security Advisory GHSA-3jff-488g-335f and the upstream commit for full technical detail.

Workarounds

Restrict cluster port 1516 to authenticated management hosts using host-based firewall rules or network segmentation
Rotate the cluster pre-shared key and treat any previously exposed key as compromised
Deploy file integrity monitoring on /var/ossec to detect unauthorized writes until patching is complete

bash

# Verify Wazuh version and confirm patched build
/var/ossec/bin/wazuh-control info | grep WAZUH_VERSION

# Restrict cluster port to trusted management subnet
iptables -A INPUT -p tcp --dport 1516 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 1516 -j DROP

# Rotate the cluster key and restart the manager
openssl rand -hex 16 | tee /var/ossec/etc/cluster.key
systemctl restart wazuh-manager