
Cloud Vulnerability DB
A community-led vulnerabilities database
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).
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).
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).
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).
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.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.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).process_files_from_worker(), which moves the payload to /var/ossec/etc/ossec.conf with wazuh:wazuh ownership and mode 640./manager/restart API call). The attacker-controlled ossec.conf is loaded, and wazuh-logcollector (running as root) executes the injected commands (GitHub Advisory).hello handshakes from unrecognized peer node names (e.g., random or attacker-chosen names not in the expected worker list)./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)./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.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).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).
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).
Source: This report was generated using AI
Free Vulnerability Assessment
Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.
Get a personalized demo
"Best User Experience I have ever seen, provides full visibility to cloud workloads."
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
"We know that if Wiz identifies something as critical, it actually is."