Wazuh CVE-2026-30893 Cluster Sync RCE Vulnerability

A critical path traversal vulnerability in Wazuh’s cluster synchronization mechanism, tracked as CVE-2026-30893 with a CVSS score of 9.0, allows an authenticated cluster peer to write arbitrary files across all cluster nodes and escalate to full remote code execution (RCE).

All deployments running Wazuh versions 4.4.0 through 4.14.3 are affected, and administrators are urged to upgrade to version 4.14.4 or later immediately.

Wazuh is a widely deployed, free, and open-source security platform used by enterprises worldwide for threat prevention, detection, and response.

Its cluster architecture allows controller and worker nodes to synchronize integrity data and configuration files in real time, a design feature that this vulnerability weaponizes.

The vulnerability was discovered by security researcher Alimezar and published by Vikman90 on GitHub under advisory GHSA-m8rw-v4f6-8787.

The severity of this flaw cannot be overstated: in Docker deployments where the Wazuh cluster daemon commonly runs as root, exploitation leads to full system-level compromise.

Given how widely Wazuh is used as a security operations backbone, a compromised Wazuh cluster can blind an organization’s entire detection capabilities while simultaneously serving as a launchpad for lateral movement.

Wazuh CVE-2026-30893: Cluster Sync Vulnerability

The root cause lies in Wazuh’s decompress_files() function located in framework/wazuh/core/cluster/cluster.py (lines 454–465). The function constructs output file paths by passing attacker-controlled filepath values directly to os.path.join() without any sanitization, normalization, or path containment check.

This critical oversight opens two distinct exploitation paths:

Relative path traversal: A crafted filepath, such as ../../../../etc/cron.d/backdoor escapes the intended extraction directory entirely.
Absolute path injection: A filepath beginning with / (e.g., /etc/cron.d/backdoor) causes Python’s os.path.join() to silently discard the base directory and write directly to the injected absolute path.

The cluster sync archive format embeds raw filepaths in the payload as filepath|//@@//|zlib(content), and these values are fully controlled by the sending peer.

The receiving peer extracts them with zero validation, trusting the sender implicitly, a fundamental design flaw in extraction path containment that CWE-22 (Path Traversal) and CWE-73 (External Control of File Name or Path) both classify as high-risk weaknesses.

The decompress_files() function is invoked during normal cluster operations at three separate call sites, making the attack surface broad:

master.py:744 — in integrity_check() when processing worker integrity metadata
master.py:836 — in sync_worker_files() when processing extra-valid files from workers
worker.py:725 — in update_master_files_in_worker() When processing files from the master

This means both master-to-worker and worker-to-master propagation paths are exploitable. A malicious cluster peer only needs the cluster key, a 32-character shared secret, stored in ossec.conf to authenticate and inject the crafted archive.

Once inside the cluster trust boundary, the vulnerability triggers after transfer during decompression, bypassing any transport-layer restrictions on where files can be written.

According to the CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:HThe attack is network-reachable, requires no user interaction, has low attack complexity, and changesscope, meaning the blast radius extends beyond the initially compromised component.

The real-world impact of CVE-2026-30893 scales directly with the effective UID of the Wazuh cluster daemon:

Default installation (wazuh user, uid 999): Arbitrary file write to all paths writable by the wazuh user; overwrite of Python modules in /var/ossec/wodles/ to gain Wazuh-context code execution; tampering with Wazuh configuration in /var/ossec/etc/.
Elevated context (root common in Docker deployments): Full system compromise via writes to /etc/cron.d/, /root/.ssh/authorized_keys, or any other system-critical path.

A proof-of-concept (PoC) exploit is publicly available. The PoC directly invokes decompress_files() with a crafted archive containing traversal paths and demonstrates file creation at /tmp/PWNED_ABSOLUTE.txt, /tmp/PWNED_TRAVERSAL.txt, and /etc/cron.d/wazuh_exploit. The existence of a working public PoC dramatically increases the risk of active exploitation in the wild.

Mitigation

Wazuh released the fix in version 4.14.4 (released March 17, 2026). The patch resolves the path containment failure by introducing proper normalization and validation of filepaths before they are passed to os.path.join(). All organizations running Wazuh in cluster mode on versions 4.4.0 through 4.14.3 must upgrade immediately.

Administrators should take the following steps in parallel with patching:

Upgrade to Wazuh ≥ 4.14.4 across all master and worker nodes simultaneously to eliminate the vulnerability window.
Audit cluster key exposure: Rotate the 32-character cluster key ossec.conf if any unauthorized access to the key is suspected.
Restrict cluster daemon privileges: Avoid running the Wazuh daemon as root, especially in Docker/container environments, and enforce the principle of least privilege.
Review filesystem integrity: Inspect /etc/cron.d/, /var/ossec/wodles/, and /root/.ssh/ for unauthorized or unexpected files that could indicate prior exploitation.
Network segmentation: Restrict cluster port access (default TCP 1516) to known trusted IPs using firewall rules or security group policies.

FAQ

Q1: Does CVE-2026-30893 require external network access to exploit?

No exploitation requires an authenticated cluster peer, meaning the attacker must already hold a valid cluster key and network access to cluster port 1516, but no external internet exposure is needed.

Q2: Is a public proof-of-concept exploit available for this vulnerability?

Yes, a working PoC (poc_complete.py) is publicly available and directly invokes the vulnerable decompress_files() function to write files to arbitrary paths.

Q3: Which versions of Wazuh are confirmed as safe from CVE-2026-30893?

Wazuh version 4.14.4 and all later releases (including 4.14.5, released April 23, 2026) contain the patch and are not affected by this vulnerability.

Q4: Can this vulnerability enable lateral movement across all cluster nodes?

Yes, because the cluster architecture involves both master-to-worker and worker-to-master sync paths, a single compromised node with a valid cluster key can propagate the exploit to every node in the cluster.

Site: thecybrdef.com

For more insights and updates, follow us on Google News, Twitter, and LinkedIn.