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

CVE-2026-48024 is a path traversal vulnerability in the Wazuh cluster synchronization mechanism that allows a cluster peer holding the shared Fernet key to write arbitrary files anywhere the wazuh user has write access on the master node, including /var/ossec/etc/ossec.conf. Affected versions span from 4.0.0 through 4.14.5 and 5.0.0-beta1 through 5.0.0-beta2. The vulnerability was reported by researcher moltenbit, published on August 19, 2026, and carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory, Feedly). Fixed versions are 4.14.6 and 5.0.0-beta3 (v4.14.6 Release, v5.0.0-beta3 Release).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). The vulnerable function cluster.unmerge_info() in framework/wazuh/core/cluster/cluster.py (lines 711–762) constructs destination paths by joining peer-controlled merge_type and name values from merged synchronization archive headers without sanitizing .. sequences or path separators. The caller process_files_from_worker() in master.py (lines 891–923) only confines the resulting path to the outer WAZUH_PATH (/var/ossec/) boundary via safe_join, but does not restrict writes to the intended cluster sync subdirectory. An attacker crafts a malicious files_metadata.json with a merge_type such as ../etc and a merge_name of payload.merged, causing the master to write attacker-controlled content to /var/ossec/etc/ossec.conf. A peer-controlled future timestamp in the merged-file header also bypasses the mtime-based skip optimization, guaranteeing overwrite of existing files. A full proof-of-concept is included in the advisory (GitHub Advisory, Fix Commit).

Successful exploitation allows a malicious cluster peer to overwrite /var/ossec/etc/ossec.conf with attacker-controlled content, which can configure root-executed commands that are triggered when Wazuh services reload — resulting in remote code execution as root via wazuh-logcollector. Beyond ossec.conf, the write primitive extends to agent configuration files (agent.conf, merged.mg) distributed cluster-wide to all connected agents, Python wodle scripts loaded by wazuh-modulesd, detection rule and decoder files, and Wazuh log files — enabling cluster-wide detection suppression, false alert injection, and forensic log tampering. The impact chain is identical to that established for CVE-2026-25770, and the master node's central coordinator role means compromise propagates to the entire Wazuh deployment including all managed agents (GitHub Advisory).

A detailed proof-of-concept exploit (Python scripts h2_poc_ossec_conf.py and cluster_client.py) is publicly included in the GitHub Security Advisory, demonstrating the full attack in approximately 5 wire round-trips (~200 ms) against a stock Docker deployment (GitHub Advisory). The attacker requires network access to the cluster port (default TCP/1516) and the 32-byte Fernet cluster key — no prior worker registration is needed. The EPSS score is currently 0.0, and there is no confirmed in-the-wild exploitation or CISA KEV catalog listing as of the publication date (Feedly). Community discussion was noted on Mastodon and security news outlets shortly after disclosure (SecurityOnline).

1. Obtain the cluster Fernet key: Retrieve the 32-byte cluster key from a backed-up ossec.conf, a compromised cluster peer, or by reading it from a worker node with filesystem access.
2. Identify the target: Confirm network reachability to the Wazuh master's cluster port (default TCP/1516). The cluster name and protocol version are transmitted in cleartext and can be fingerprinted from legitimate peer traffic.
3. Perform the cluster handshake: Using the PoC cluster_client.py, connect to the master and send a hello opcode with an arbitrary peer name, the cluster name, type worker, and matching version. The master responds ok Client added.
4. Open a sync task: Send syn_e_w_m with an empty payload; the master returns a fresh task UUID.
5. Craft the malicious archive: Build a Wazuh cluster archive containing two entries: (a) payload.merged — a merged-bundle with a header specifying merge_type: ../etc and a filename of ossec.conf with a future mtime (e.g., 2099-01-01), and (b) files_metadata.json describing the merged entry with cluster_item_key: etc/shared/.
6. Upload the archive: Send new_file, file_upd (with the archive payload), and file_end (with the SHA-256 digest) opcodes referencing the path queue/cluster/<node_name>/payload.zip.
7. Trigger processing: Send syn_e_w_m_e with the task UUID and archive path. The master asynchronously decompresses the archive, calls unmerge_info() with the attacker-supplied merge_type and merge_name, and safe_move writes the payload to /var/ossec/etc/ossec.conf.
8. Achieve root code execution: The overwritten ossec.conf contains a <command> block with attacker-controlled commands. On the next Wazuh service reload, wazuh-logcollector executes these commands as root (GitHub Advisory).

• Network: Unexpected TCP connections to the Wazuh cluster port (default 1516) from unknown or unauthorized IP addresses; new peer names appearing in cluster logs that do not correspond to registered worker nodes.
• File System: Unexpected modification timestamp on /var/ossec/etc/ossec.conf (especially a far-future date such as year 2099); reduced file size of ossec.conf compared to baseline; presence of unexpected files under /var/ossec/etc/, /var/ossec/etc/rules/, /var/ossec/etc/decoders/, or /var/ossec/wodles/; new or modified .py files in wodle directories.
• Logs: Entries in cluster.log showing a new peer name completing a handshake followed immediately by syn_e_w_m and syn_e_w_m_e operations without prior registration; WazuhException 3052 errors (post-patch) indicating blocked traversal attempts; unexpected safe_move operations in cluster debug logs targeting paths outside queue/cluster/.
• Process: Unexpected child processes spawned by wazuh-logcollector or wazuh-modulesd (e.g., shells, curl, wget, reverse shell processes) following a service reload (GitHub Advisory).

Upgrade to Wazuh 4.14.6 or 5.0.0-beta3, which include the fix merged via PR #36204 (v4.14.6 Release, v5.0.0-beta3 Release). The fix adds validation in unmerge_info() to reject merge_type and filename values containing /, \, or starting with .; normalizes header filenames to single path components via os.path.basename(); validates cluster_item_key against the configured cluster items allowlist; and adds path confinement checks in both process_files_from_worker() and overwrite_or_create_files() to restrict writes to the authorized sync subdirectory (Fix Commit). As a network-level workaround where immediate patching is not possible, restrict access to the cluster port (TCP/1516) to only trusted cluster peer IP addresses using firewall rules, and rotate the cluster Fernet key if it may have been exposed.

The vulnerability was reported by researcher moltenbit and discussed on Mastodon shortly after the advisory was published (Feedly). Security news outlet SecurityOnline.info covered the broader set of Wazuh manager cluster vulnerabilities disclosed around the same time (SecurityOnline). The advisory explicitly links this flaw as a sibling of CVE-2026-25770 and CVE-2026-30893, indicating a pattern of cluster trust boundary issues being identified and addressed in the Wazuh codebase during this period.