CVE-2026-49441: Wazuh RCE Vulnerability

CVE-2026-49441 Overview

CVE-2026-49441 is a path traversal vulnerability in Wazuh, the open source threat prevention, detection, and response platform. The flaw resides in the process_files_from_worker() function in framework/wazuh/core/cluster/master.py. The non-merged branch trusts a peer-controlled file_path key from files_metadata.json and joins it to WAZUH_PATH without confirming the destination stays inside the directory selected by cluster_item_key. A cluster peer holding the shared Fernet key can upload a crafted extra-valid archive and overwrite sensitive files such as /var/ossec/etc/ossec.conf. The issue affects Wazuh versions from 4.3.0 up to 4.14.6 and 5.0.0-beta3.

Critical Impact
An authenticated cluster peer can overwrite ossec.conf to configure root-executed commands, achieving code execution as root after a service reload.

Affected Products

Wazuh 4.3.0 through 4.14.5
Wazuh 5.0.0-beta1 and 5.0.0-beta2
Wazuh master node cluster component (framework/wazuh/core/cluster/master.py)

Discovery Timeline

2026-08-19 - CVE-2026-49441 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-49441

Vulnerability Analysis

The vulnerability is a path traversal flaw [CWE-73] in the Wazuh master node cluster synchronization logic. When a worker node sends an integrity update, the master processes an archive containing files described by files_metadata.json. The non-merged branch of process_files_from_worker() reads the file_path value from that metadata and joins it to WAZUH_PATH to compute the destination. The code does not verify that the resulting path stays within the directory implied by cluster_item_key.

A peer that possesses the shared Fernet key used for cluster communication can craft an archive with a file_path that escapes the intended directory. The master then writes the attacker-supplied file contents to any location under WAZUH_PATH, including /var/ossec/etc/ossec.conf. Because ossec.conf can define commands executed by the Wazuh manager as root, replacing it and triggering a service reload leads to root code execution on the master node.

Root Cause

The root cause is missing validation of an externally influenced pathname. The file_path field originates from a cluster peer but is treated as trusted input. Without a containment check against the directory selected by cluster_item_key, safe_join alone does not prevent traversal into unrelated sensitive directories.

Attack Vector

Exploitation requires an attacker to control a Wazuh cluster peer or otherwise possess the shared Fernet key. The attacker submits a crafted extra-valid archive during normal cluster synchronization. No user interaction on the master node is required. The scope changes because a compromised worker or peer can escalate to root code execution on the master node after a configuration reload.

python

# Security patch in framework/wazuh/core/cluster/master.py
# fix(cluster): validate file path parameter in non-merged sync

# If the file is not 'merged' type, move it directly to the destination path.
else:
    try:
        expected_base = safe_join(common.WAZUH_PATH, item_key)
        if not os.path.commonpath([full_path, expected_base]).startswith(expected_base):
            raise exception.WazuhClusterError(3022,
                extra_message=f"File path outside allowed directory: {file_path}")

        file_basename = os.path.basename(file_path)
        if file_basename in cluster_items['files'].get('excluded_files', []):
            raise exception.WazuhClusterError(3022,
                extra_message=f"File is in excluded list: {file_path}")

        zip_path = safe_join(decompressed_files_path, file_path)
        utils.safe_move(zip_path, full_path, ownership=(common.wazuh_uid(), common.wazuh_gid()),
                        permissions=cluster_items['files'][item_key]['permissions'])

Source: GitHub Commit 7f13682. The patch computes the expected_base for the given item_key and rejects any resolved destination path that falls outside it. It also enforces an excluded-files list to block writes to known sensitive filenames.

Detection Methods for CVE-2026-49441

Indicators of Compromise

Unexpected modification timestamps on /var/ossec/etc/ossec.conf or other files under /var/ossec/ on cluster master nodes.
Presence of <command> or <localfile> entries in ossec.conf referencing unfamiliar binaries, shell payloads, or paths outside /var/ossec/.
Wazuh manager service restarts or reloads that do not correspond to a scheduled change.
Cluster synchronization events involving file_path values containing .. or absolute paths escaping the expected cluster_item_key directory.

Detection Strategies

Monitor file integrity on ossec.conf, authd.pass, client.keys, and other files under /var/ossec/etc/ on master and worker nodes.
Parse Wazuh cluster logs (/var/ossec/logs/cluster.log) for path errors, permission errors, or unexpected non-merged file writes.
Compare deployed ossec.conf against a version-controlled baseline after each cluster sync.

Monitoring Recommendations

Alert on any process spawned by wazuh-execd or ossec-execd whose command line is not on an approved allowlist.
Track possession and rotation of the cluster Fernet key; treat any leak as a trigger for immediate rotation.
Ingest Wazuh cluster and manager logs into a centralized SIEM with correlation rules for configuration changes followed by service reloads.

How to Mitigate CVE-2026-49441

Immediate Actions Required

Upgrade Wazuh cluster master and worker nodes to version 4.14.6 or 5.0.0-beta3.
Rotate the shared cluster Fernet key after patching to invalidate any keys held by potentially compromised peers.
Verify the integrity of ossec.conf and other files under /var/ossec/etc/ on all master nodes and restore known-good copies where needed.
Restrict network access to the cluster port so only trusted worker nodes can reach the master.

Patch Information

The fix is available in Wazuh 4.14.6 and Wazuh 5.0.0-beta3. The code change is documented in GitHub Commit 7f13682 and Pull Request #36296. See the GitHub Security Advisory GHSA-3v57-hgvj-3vj2 for the vendor advisory.

Workarounds

Isolate the cluster network segment and enforce mutual authentication between master and worker nodes at the network layer.
Enable strict file integrity monitoring on /var/ossec/etc/ossec.conf and alert on any change outside a maintenance window.
Reduce the number of cluster peers holding the Fernet key and store the key in a hardware-backed or vault-managed secret store.

bash

# Verify installed Wazuh version and upgrade on Debian/Ubuntu
dpkg -l | grep wazuh-manager
apt-get update && apt-get install --only-upgrade wazuh-manager=4.14.6-1

# Verify installed Wazuh version and upgrade on RHEL/CentOS
rpm -q wazuh-manager
yum update wazuh-manager-4.14.6-1

# Confirm ossec.conf integrity against a known-good baseline
sha256sum /var/ossec/etc/ossec.conf

# Restart the manager after validating configuration
systemctl restart wazuh-manager