CVE-2026-49441
Wazuh Server vulnerability analysis and mitigation

Overview

CVE-2026-49441 is a path traversal / arbitrary file write vulnerability in the Wazuh cluster manager that allows an authenticated cluster peer to overwrite security-sensitive files under /var/ossec/ on the master node, ultimately enabling root remote code execution. It affects Wazuh versions 4.3.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 fixed in versions 4.14.6 and 5.0.0-beta3. It carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory).

Technical details

The root cause is CWE-73 (External Control of File Name or Path): the non-merged branch of process_files_from_worker() in framework/wazuh/core/cluster/master.py (lines 882–935) consumes the top-level key from a peer-supplied files_metadata.json directly as the destination file path, joining it to WAZUH_PATH via safe_join without verifying that the resolved path remains within the directory implied by cluster_item_key. The only existing filter is a basename check for client.keys, leaving all other paths under /var/ossec/ reachable by the wazuh process. An attacker who possesses the shared Fernet cluster key can craft a malicious archive with a files_metadata.json declaring cluster_item_key: "etc/" and file_path: "etc/ossec.conf", then deliver it via the standard syn_e_w_m extra-valid sync flow over TCP/1516. This is a sibling code path to CVE-2026-25770, which patched the merged-file branch but left the non-merged branch unaddressed. A proof-of-concept script (h3_ossec_overwrite.py) is included in the advisory and demonstrates verified overwrite of /var/ossec/etc/ossec.conf in a single cluster sync request (GitHub Advisory, Fix Commit).

Impact

A cluster peer with the Fernet key gains arbitrary file write under /var/ossec/ on the master node, bounded only by directories writable by the wazuh process. The primary impact chain involves overwriting etc/ossec.conf to inject root-executed commands that trigger after a service reload via wazuh-logcollector, achieving full root RCE on the manager. Secondary impacts include alert rule and decoder injection (etc/rules/, etc/decoders/), CDB list poisoning (etc/lists/), integration script replacement (integrations/), and propagation of attacker-controlled configuration to all enrolled agents via shared group files (etc/shared/), resulting in high confidentiality, integrity, and availability impact with a changed scope (GitHub Advisory).

Exploitability

A detailed proof-of-concept exploit (h3_ossec_overwrite.py) is publicly available in the GitHub Security Advisory, demonstrating verified file overwrite against a stock Wazuh 4.14.5 Docker container. Exploitation requires network access to the cluster port (default TCP/1516) and possession of the 32-byte shared Fernet key — no prior worker registration is needed. The EPSS score is 0.0 at time of publication, and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the advisory date (GitHub Advisory).

Exploitation steps

  1. Obtain prerequisites: Acquire network reachability to the Wazuh master's cluster port (default TCP/1516) and the 32-byte shared Fernet cluster key (readable from any legitimate worker peer or compromised node).
  2. Build the malicious archive: Craft an archive containing two entries — the payload file (e.g., a malicious ossec.conf) stored under the destination key path (etc/ossec.conf), and a files_metadata.json with {"etc/ossec.conf": {"cluster_item_key": "etc/", "merged": false}}. Use standard Wazuh separators (PATH_SEP = b"|//@@//|", FILE_SEP = b"|@@//@@|"), compressing each entry with zlib.
  3. Perform the cluster handshake: Connect to TCP/1516 and send a hello message with a fresh peer name (e.g., h3_attacker_node wazuh worker 4.14.5). The cluster accepts the peer without prior registration.
  4. Execute the extra-valid sync flow: Send the five-step syn_e_w_m sequence: syn_e_w_m (get task UUID) → new_file (allocate upload slot) → file_upd (upload archive bytes) → file_end (send SHA-256 hash for verification) → syn_e_w_m_e (trigger decompression and processing).
  5. Trigger file overwrite: The master decompresses the archive and calls process_files_from_worker(), which moves the payload to /var/ossec/etc/ossec.conf with wazuh:wazuh ownership and mode 640.
  6. Achieve root RCE: Trigger a Wazuh manager restart (via cron, agent action, or the /manager/restart API call). The attacker-controlled ossec.conf is loaded, and wazuh-logcollector (running as root) executes the injected commands (GitHub Advisory).

Indicators of compromise

  • Network: Unexpected inbound TCP connections to port 1516 from unknown or untrusted IP addresses; cluster hello handshakes from unrecognized peer node names (e.g., random or attacker-chosen names not in the expected worker list).
  • Logs: Wazuh cluster logs (/var/ossec/logs/cluster.log) showing syn_e_w_m sync flows from unregistered or unexpected peer nodes; entries referencing file paths outside expected sync directories (e.g., etc/ossec.conf written via non-merged sync).
  • File System: Unexpected modification timestamp or changed SHA-256 hash on /var/ossec/etc/ossec.conf; new or modified files in /var/ossec/etc/rules/, /var/ossec/etc/decoders/, /var/ossec/etc/lists/, or /var/ossec/integrations/ with wazuh:wazuh ownership not matching expected content; presence of unfamiliar XML or script files in those directories.
  • Process: Unusual child processes spawned by wazuh-logcollector or wazuh-modulesd running as root (e.g., reverse shells, curl, wget, bash -i); unexpected wazuh-manager restart events not initiated by administrators (GitHub Advisory).

Mitigation and workarounds

Upgrade Wazuh to version 4.14.6 or 5.0.0-beta3, which add path confinement validation in process_files_from_worker() to ensure non-merged file paths remain within the directory specified by cluster_item_key (Wazuh v4.14.6 Release, Wazuh v5.0.0-beta3 Release). If immediate upgrade is not possible, restrict network access to the cluster port (TCP/1516) to only trusted worker nodes using firewall rules, and rotate the shared Fernet encryption key if any cluster peer is suspected of compromise. Monitor /var/ossec/etc/ossec.conf and other configuration directories for unauthorized modifications, and audit cluster peer node names against an expected allowlist (GitHub Advisory).

Community reactions

The vulnerability was reported by researcher moltenbit and credited in the GitHub Security Advisory. Security news outlet SecurityOnline.info covered the broader set of Wazuh manager cluster vulnerabilities disclosed around the same time. The fix was developed by Wazuh maintainer vikman90 and merged into the 4.14.6 branch on May 26, 2026, with the advisory published publicly on August 19, 2026 (GitHub Advisory, Fix PR).

Additional resources


SourceThis report was generated using AI

Related Wazuh Server vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-49441CRITICAL9.1
  • Wazuh Server logoWazuh Server
  • cpe:2.3:a:wazuh:wazuh
NoYesAug 19, 2026
CVE-2026-48162CRITICAL9.1
  • Wazuh Server logoWazuh Server
  • cpe:2.3:a:wazuh:wazuh
NoYesAug 19, 2026
CVE-2026-48024CRITICAL9.1
  • Wazuh Server logoWazuh Server
  • cpe:2.3:a:wazuh:wazuh
NoYesAug 19, 2026
CVE-2026-45798HIGH7.5
  • Wazuh Server logoWazuh Server
  • cpe:2.3:a:wazuh:wazuh
NoYesAug 19, 2026
CVE-2026-49392MEDIUM5.3
  • Wazuh Server logoWazuh Server
  • cpe:2.3:a:wazuh:wazuh
NoYesAug 19, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management