CVE-2026-61800: 
Wazuh Server vulnerability analysis and mitigation

CVE-2026-61800 is an incomplete path traversal fix in Wazuh's cluster worker file synchronization that allows a party holding the cluster key to write, overwrite, or delete arbitrary files under /var/ossec on worker nodes, leading to remote code execution as root. It affects Wazuh versions 4.4.0 through 4.14.6 (inclusive) and was published on August 28, 2026. The vulnerability is an incomplete fix for CVE-2026-30893, which addressed traversal outside /var/ossec but left the intra-directory redirection path unguarded. It carries a CVSS v3.1 base score of 9.1 (Critical) per Feedly/NVD, though the GitHub advisory rates it 8.0 (High) with a slightly different vector (Feedly, GitHub Advisory).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) in framework/wazuh/core/cluster/worker.py, specifically in the overwrite_or_create_files() helper within update_master_files_in_worker(). The merged branch of this function correctly validates that a file's destination matches its declared cluster_item_key directory using expected_base + os.path.commonpath, but the non-merged branch and the extra (delete) branch omit this check entirely — safe_join() only confines paths to /var/ossec without tying them to their declared subdirectory. An attacker holding the cluster key can craft a malicious integrity sync zip with a files_metadata.json that specifies a file path such as active-response/bin/run.sh with a cluster_item_key of etc/shared/ — the key is only used for a permissions lookup and is never compared against the destination path, so the file lands wherever the attacker specifies within /var/ossec (GitHub Advisory, GitHub Commit).

A successful exploit allows a compromised master node or any holder of the cluster key (a single shared secret distributed to all nodes) to write or overwrite any file under /var/ossec on every worker node in the cluster, and to delete arbitrary files via the extra branch. Because several paths under /var/ossec — including active-response/bin/, wodles/, integrations/, and bin/ — are executed as root, this translates to remote code execution as root across the entire worker fleet, with full confidentiality, integrity, and availability impact. Configuration files such as etc/ossec.conf and etc/internal_options.conf can also be overwritten to alter behavior on restart (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of publication. The NVD SSVC assessment indicates exploitation is "none" and the attack is not automatable, reflecting the high-privilege precondition of holding the cluster key or controlling a master node. The EPSS score is 0.0059 (approximately 0.59%), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (Feedly, GitHub Advisory).

1. Obtain cluster key: Acquire the Wazuh cluster key (a shared secret present on all cluster nodes), either by compromising a master node, intercepting it from configuration files (/var/ossec/etc/ossec.conf), or through insider access.
2. Identify target workers: Enumerate worker nodes reachable on the cluster communication port (default TCP 1516) using network scanning or existing cluster topology knowledge.
3. Craft malicious sync payload: Build a ZIP archive containing the malicious file (e.g., a reverse shell script) at the desired path (e.g., active-response/bin/run.sh) and a files_metadata.json such as:

{
  "missing": {
    "active-response/bin/run.sh": {
      "merged": false,
      "cluster_item_key": "etc/shared/",
      "blake2b": "<hash_of_payload>"
    }
  },
  "shared": {},
  "extra": {}
}

4. Deliver via cluster sync: Act as or impersonate the master node and push the crafted integrity sync ZIP to the worker. The worker's update_master_files_in_worker() non-merged branch will write the file to /var/ossec/active-response/bin/run.sh without validating the destination against cluster_item_key.
5. Trigger execution as root: Initiate an active response from the master (or wait for a scheduled event) to cause wazuh-execd to execute the planted script as root, achieving full system compromise on the worker node (GitHub Advisory, GitHub Commit).

• File System: Unexpected or recently modified files in /var/ossec/active-response/bin/, /var/ossec/wodles/, /var/ossec/integrations/, or /var/ossec/bin/ that do not correspond to legitimate Wazuh updates; new or altered scripts with unusual content or permissions in these directories.
• File System: Modifications to /var/ossec/etc/ossec.conf or /var/ossec/etc/internal_options.conf not initiated by an administrator.
• Logs: Wazuh cluster logs (/var/ossec/logs/cluster.log) showing file sync operations placing files in directories inconsistent with their declared cluster_item_key (e.g., etc/shared/ key but destination in active-response/bin/).
• Logs: WazuhClusterError 3022 entries in cluster logs may appear after patching if exploitation is attempted against a patched node, indicating blocked traversal attempts.
• Process: Unexpected child processes spawned by wazuh-execd or wazuh-modulesd running scripts not part of the standard Wazuh installation; unusual outbound network connections from worker nodes.
• Network: Anomalous cluster communication on TCP port 1516 originating from unexpected source IPs or at unusual times, particularly involving large ZIP transfers (GitHub Advisory).

Wazuh has released version 4.14.7 as the patched release, which applies the same expected_base + os.path.commonpath destination confinement check to the non-merged and extra branches of update_master_files_in_worker(), and also validates that cluster_item_key exists in cluster_items['files'] before use. Organizations should upgrade all Wazuh manager nodes (master and workers) to version 4.14.7 or later as the primary remediation. As a temporary workaround where immediate upgrade is not possible, restrict network access to the cluster communication port (TCP 1516) to only trusted, known-good master nodes, and audit the cluster key to ensure it has not been compromised (GitHub Advisory, GitHub Commit).

The vulnerability was independently reported by two researchers, @evilgensec and @karasu-hakira (Hakira), who are credited in the official GitHub Security Advisory for coordinated disclosure. The Wazuh security team published the advisory on August 18, 2026, and released the fix in version 4.14.7. No significant broader media coverage or notable social media commentary beyond the advisory itself has been identified (GitHub Advisory).