CVE-2026-74044 in wazuh-manager
Summary
by MITRE • 08/18/2026
Wazuh 4.0.0 before 4.14.6 contains a path traversal vulnerability that allows authenticated cluster peers to delete arbitrary directory contents by supplying a traversal-shaped node name in the cluster hello payload without validation. Attackers holding a valid cluster Fernet key can craft a malicious node name and disconnect, triggering the master's peer cleanup routine to remove the contents of arbitrary directories within the Wazuh installation path writable by the wazuh user.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Wazuh versions prior to 4.14.6 represents a critical security flaw rooted in insufficient input validation during cluster initialization processes. Specifically, this is a Path Traversal vulnerability that affects authenticated cluster peers within the Wazuh management infrastructure. The core technical issue lies in how the master node handles the hello payload sent by peer nodes attempting to join or rejoin the cluster. When a peer sends its identification information, including a node name, the system fails to adequately sanitize this input before processing it for directory cleanup operations. This lack of validation allows an attacker who possesses valid authentication credentials and a legitimate Fernet encryption key to inject maliciously crafted strings into the node name field. These strings are designed with path traversal sequences that bypass standard directory boundaries, effectively tricking the master node's peer cleanup routine into interpreting arbitrary file system paths as part of the intended cluster management operations.
From an operational perspective, this flaw enables a severe impact scenario where an authenticated attacker can delete arbitrary directory contents within the Wazuh installation hierarchy. The attack vector relies on the timing and mechanics of the cluster synchronization process. By supplying a traversal-shaped node name in the hello payload and subsequently disconnecting from the cluster, the trigger for the master's cleanup routine is activated. This routine, designed to remove stale or disconnected peer data directories, proceeds without verifying that the target path remains within the expected sandboxed environment. Consequently, if the wazuh user has write permissions over specific system directories, which is often necessary for log collection and agent management functions, the attacker can cause destructive modifications to critical configuration files, logs, or other sensitive data stored in those locations. This capability undermines the integrity of the security monitoring platform itself, potentially leading to service disruption, loss of historical telemetry data, or further exploitation if deleted components are replaced with malicious alternatives during subsequent restarts.
This vulnerability aligns closely with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as it involves accessing files outside the intended directory structure due to inadequate sanitization of user-supplied input. In terms of attack classification under the MITRE ATT&CK framework, this behavior is consistent with T1083: File and Directory Discovery combined with T1485: Data Destruction or more specifically T1299: Network Service Scanning if used for reconnaissance prior to deletion, but primarily it falls under privilege abuse leading to data integrity compromise. The requirement for a valid Fernet key indicates that this is not an unauthenticated remote code execution vector but rather an authenticated insider threat or lateral movement scenario where the attacker has already compromised one of the cluster nodes and obtained its cryptographic credentials.
Mitigation strategies must prioritize immediate patching to version 4.14.6 or later, as these updates include rigorous input validation checks for node names during the hello exchange process. Administrators should also enforce strict least-privilege principles by ensuring that the wazuh user account does not possess write permissions outside of its designated operational directories. Regular audits of file system permissions within the Wazuh installation path are recommended to minimize the blast radius in case of future vulnerabilities. Additionally, monitoring cluster logs for unusual disconnection patterns or malformed hello payloads can aid in early detection of exploitation attempts before significant damage occurs. Implementing network segmentation between management and agent nodes further reduces the risk profile by limiting the ability of a compromised endpoint to interact directly with critical master node processes.