CVE-2026-74031 in Wazuh
Summary
by MITRE • 10/13/2026
Wazuh from 4.1.1 before 4.14.8 contains a path traversal vulnerability in the delete_rule_file and delete_decoder_file helpers that allows malicious cluster workers to delete arbitrary files via an unvalidated filename parameter. Attackers holding the cluster key can invoke these helpers through DistributedAPI with traversal sequences to delete ossec.conf, client.keys, or rules as the wazuh user.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified in Wazuh versions prior to 4.14.8 represents a critical path traversal flaw within the distributed architecture of the security platform. Specifically, this issue resides in the delete_rule_file and delete_decoder_file helper functions which are exposed through the DistributedAPI interface. The core technical deficiency is the lack of proper input validation on filename parameters passed by cluster workers to these deletion routines. In a typical Wazuh deployment, multiple agents or nodes communicate with central managers via a distributed API mechanism that relies on shared keys for authentication and integrity verification. While this design facilitates scalability and centralized management, it introduces an attack surface where any node possessing the valid cluster key can interact with these administrative endpoints. The vulnerability arises because the system fails to sanitize or canonicalize file paths before processing deletion requests, allowing attackers to manipulate relative path components such as dot-dot-slash sequences to escape the intended directory scope.
From a technical perspective, this flaw aligns closely with CWE-22: Improper Limitation of a Pathname to a Restricted Directory. By injecting traversal characters into the filename argument during API calls, an authenticated attacker can redirect file operations outside of the designated configuration or rules directories. This capability is particularly dangerous because it allows for the deletion of critical system files that govern the behavior and security posture of the Wazuh installation. The ability to delete arbitrary files as the wazuh user implies a significant escalation in impact beyond simple data loss, potentially leading to complete service disruption or further exploitation vectors depending on what specific files are targeted within the operating environment.
The operational impact of this vulnerability is severe due to its potential for causing denial of service and compromising the integrity of security monitoring capabilities. An attacker with access to the cluster key can target essential configuration files such as ossec.conf, which contains core settings for log collection, alerting rules, and agent configurations. Deleting or corrupting this file would likely cause the Wazuh manager or agents to fail upon restart, effectively blinding the organization to security events. Additionally, targeting client.keys could disrupt authentication mechanisms between nodes, while deleting rule files removes the logic used to detect malicious activity. This not only halts immediate threat detection but also undermines trust in the integrity of the logging infrastructure itself. The attack vector is classified under MITRE ATT&CK technique T1070: Indicator Removal on Host, specifically within the context of file deletion or modification to hinder forensic analysis and system stability.
Mitigation strategies must focus on both immediate remediation and long-term architectural hardening. The primary solution is to upgrade Wazuh installations immediately to version 4.14.8 or later, where this path traversal issue has been addressed through improved input validation and strict file path canonicalization checks before any deletion operation is executed. In environments where upgrading is not instantly feasible, network segmentation should be enforced to restrict access to the DistributedAPI endpoints only from trusted management networks. Furthermore, principle of least privilege dictates that cluster keys should have minimal permissions necessary for their function, and regular rotation of these credentials can limit the window of opportunity for exploitation if a key is compromised. Security teams should also monitor logs for unusual API calls involving file deletion operations or anomalous path structures to detect potential attempts at exploiting this vulnerability before significant damage occurs.