CVE-2026-54083: Wazuh: Path traversal in ip-customblock active response allows arbitrary file creation and deletion
Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. The ip-customblock active response script contains a path traversal vulnerability that lets an attacker create or delete arbitrary files on the filesystem as root. The script builds a file path by concatenating the srcip field taken from alert JSON directly onto the fixed /ipblock/ base directory, without validating that the value is a well-formed IP address. Because the extraction routine returns the raw string unchecked, an attacker who can trigger alert-matching log events with a crafted srcip containing ../ sequences can escape the base directory. The block action opens the resulting path in append mode, creating an empty file at an arbitrary location, while the unblock action passes it to remove(), deleting an arbitrary file; since the active response daemon runs as root, this includes sensitive files such as system credentials and Wazuh configuration. Unlike the sibling scripts host-deny.c, default-firewall-drop.c, and firewalld-drop.c, which reject non-IP input via getipversion(), ip-customblock.c omits this validation. This issue is fixed in version 4.14.7.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Wazuh ip-customblock active response scriptto a version that resolves this vulnerability.Fixed in 4.14.7 - Configuration
Modify the ip-customblock active response script to reject non-IP input by validating the srcip field (e.g., as sibling scripts do with get_ip_version()), preventing srcip values containing path traversal sequences (e.g., ../) from being concatenated onto /ipblock/.
ip-customblock active response (ip-customblock.c) srcip validation using get_ip_version() = enable
Event History
Frequently Asked Questions
Who is exposed to exploitation?
Systems using the ip-customblock active response script are exposed if an attacker can trigger alert-matching log events and control the srcip value in the resulting alert JSON. The issue affects the script because it accepts srcip values without confirming that they are valid IP addresses.
What level of access does an attacker need?
The attacker needs the ability to cause alert-matching log events containing a crafted srcip value with ../ path traversal sequences. No direct administrative access is described, but exploitation depends on reaching an alert path that invokes the vulnerable active response.
What can an attacker do after successful exploitation?
The block action can create an empty file at an arbitrary filesystem location, and the unblock action can delete an arbitrary file. These operations run as root, so sensitive system files and Wazuh configuration may be affected.
Is this mitigated by using other Wazuh active response scripts?
The described issue is specific to ip-customblock.c. The sibling host-deny.c, default-firewall-drop.c, and firewalld-drop.c scripts validate non-IP input through get_ip_version(), while ip-customblock.c does not.
What remediation is available?
The issue is fixed in Wazuh version 4.14. If updating is not immediately possible, avoid using the vulnerable ip-customblock active response script where untrusted or attacker-influenced srcip values can reach alert-matching events.