CVE-2026-54083: Wazuh Path Traversal Vulnerability

CVE-2026-54083 Overview

CVE-2026-54083 is a path traversal vulnerability in the Wazuh open-source security platform, which provides unified XDR and SIEM protection for endpoints and cloud workloads. The flaw resides in the ip-customblock active response script, which builds a filesystem path by concatenating the srcip field from alert JSON directly onto the /ipblock/ base directory. The script omits the get_ip_version() validation used by sibling scripts, allowing an attacker who can trigger alert-matching log events with a crafted srcip containing ../ sequences to escape the base directory. Because the active response daemon runs as root, an attacker can create empty files at arbitrary locations or delete arbitrary files, including system credentials and Wazuh configuration. The issue is fixed in version 4.14.7.

Critical Impact
An authenticated attacker able to inject alert-matching log events can create or delete arbitrary files on the Wazuh server as root, enabling denial of service and integrity compromise of sensitive system and configuration files.

Affected Products

Wazuh server versions prior to 4.14.7
Wazuh ip-customblock active response script (src/active-response/ip-customblock.c)
Deployments using the ip-customblock active response action

Discovery Timeline

2026-08-28 - CVE-2026-54083 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-54083

Vulnerability Analysis

The vulnerability is a classic path traversal flaw [CWE-22] in the ip-customblock.c active response handler. Wazuh active response scripts receive alert JSON on standard input and extract fields such as srcip to drive block or unblock actions. The ip-customblock script constructs the target file path using the raw srcip string appended to a fixed /ipblock/ base directory.

The block action opens the constructed path in append mode, which creates an empty file at that location if it does not already exist. The unblock action passes the same path to remove(), deleting the file at that location. Because the Wazuh active response daemon executes as root, both primitives operate with full filesystem privileges.

Root Cause

The extraction routine returns the srcip value unchecked and never verifies that it is a well-formed IP address. Sibling active response scripts including host-deny.c, default-firewall-drop.c, and firewalld-drop.c call get_ip_version() to reject non-IP input, but ip-customblock.c omits this validation. An attacker-controlled srcip value containing ../ sequences therefore propagates directly into filesystem operations.

Attack Vector

An attacker who can generate log events that match active response rules can supply a crafted srcip value. When the alert is dispatched, the active response daemon executes ip-customblock with the malicious value. The block action creates an empty file at any writable location, corrupting configuration files or planting marker files. The unblock action deletes arbitrary files, including /var/ossec/etc/client.keys, /etc/shadow, or Wazuh configuration files, breaking authentication or disabling the platform.

         return OS_INVALID;
     }
 
+    if (get_ip_version(srcip) == OS_INVALID) {
+        memset(log_msg, '\0', OS_MAXSTR);
+        snprintf(log_msg, OS_MAXSTR - 1, "Unable to run active response (invalid IP: '%s')", srcip);
+        write_debug_file(argv[0], log_msg);
+        cJSON_Delete(input_json);
+        return OS_INVALID;
+    }
+
     if (action == ADD_COMMAND) {
         char **keys = NULL;
         int action2 = OS_INVALID;

Source: GitHub Wazuh Commit e6ef990. The patch adds a get_ip_version() check that rejects any srcip value that is not a valid IPv4 or IPv6 address, aborting the active response with a diagnostic log entry.

Detection Methods for CVE-2026-54083

Indicators of Compromise

Unexpected empty files under paths outside /var/ossec/ipblock/, particularly in system directories such as /etc/, /var/, or /root/.
Missing or truncated Wazuh files such as client.keys, ossec.conf, or agent authentication material without a corresponding administrative change.
Log entries from the active response daemon referencing srcip values containing ../, encoded traversal sequences, or absolute paths.

Detection Strategies

Parse Wazuh active-responses.log for ip-customblock invocations and flag any srcip value that fails IPv4 or IPv6 syntax validation.
Correlate active response executions with filesystem create and unlink events outside the /var/ossec/ipblock/ directory using file integrity monitoring.
Alert on rule matches that feed ip-customblock when the originating log source contains attacker-controllable fields mapped to srcip.

Monitoring Recommendations

Enable Wazuh File Integrity Monitoring (FIM) on /var/ossec/etc/, /etc/, and other sensitive directories on the Wazuh server.
Forward active-responses.log and ossec.log to a centralized analytics platform for retention and correlation.
Baseline the set of srcip values that trigger active responses and alert on deviations from expected IP address formats.

How to Mitigate CVE-2026-54083

Immediate Actions Required

Upgrade Wazuh to version 4.14.7 or later on all manager nodes running active response.
Audit active response configurations and temporarily disable the ip-customblock command on unpatched managers.
Review filesystem integrity on Wazuh manager hosts for missing or unexpected empty files created after the vulnerable script was deployed.

Patch Information

The fix is committed in Wazuh commit e6ef990 and shipped in Wazuh 4.14.7. See the GitHub Security Advisory GHSA-m4mf-qmhf-8vj6 for vendor guidance. The patch validates the srcip field with get_ip_version() and aborts the active response when the value is not a well-formed IP address.

Workarounds

Remove or comment out the ip-customblock command block in ossec.conf until the upgrade is applied.
Restrict which decoders and rules can populate the srcip field to trusted log sources only.
Constrain filesystem permissions on the Wazuh installation directory so accidental writes outside /var/ossec/ipblock/ are logged by auditd.

bash

# Disable the vulnerable active response in /var/ossec/etc/ossec.conf
# Comment out the ip-customblock command and any <active-response> block referencing it:
#
# <command>
#   <name>ip-customblock</name>
#   <executable>ip-customblock</executable>
#   <timeout_allowed>yes</timeout_allowed>
# </command>

sudo systemctl restart wazuh-manager

# Verify installed version after upgrading
/var/ossec/bin/wazuh-control info | grep WAZUH_VERSION