CVE-2026-54085

Executive Summary

CVE-2026-54085 is a command argument injection vulnerability in Wazuh versions 4.2.0 through 4.14.6, affecting multiple active response scripts that pass attacker-influenced alert fields to privileged system commands without validating their format. An attacker able to inject crafted log events (e.g., via syslog) can supply malicious srcip or dstuser values that, when an active response rule triggers, are passed unvalidated to firewall and account-management commands executing as root. This enables argument injection, potentially allowing arbitrary system account locking and, on Windows, additional command-line argument injection via unquoted CreateProcess command-line concatenation. The vulnerability is fixed in version 4.14.7.

Technical Analysis

The vulnerability resides in Wazuh's active response framework, which automatically executes pre-defined scripts when security alerts match configured rules. Specific scripts process alert-derived fields and pass them directly to system commands without adequate format validation.

Vulnerable Components:

• route-null.c, netsh.c, pf.c, npf.c, ipfw.c: Five of eight scripts handling the srcip field omit the get_ip_version() validation check. This function normally rejects non-IP input, ensuring only properly formatted IP addresses are processed. Without this check, arbitrary strings can flow into firewall commands (pfctl, npfctl, ipfw, route, netsh) that execute with root privileges.

• disable-account.c: This script passes the dstuser field to passwd/chuser commands with only a comparison against the literal string "root". No other validation is performed, allowing arbitrary account names to be passed to privileged account-management commands.

Attack Mechanism:

The injection occurs through alert fields. Wazuh normalizes log events into alerts; fields such as srcip (source IP) and dstuser (destination user) are parsed from log sources. When an attacker can control log content arriving at the Wazuh manager, they can set these fields to values containing shell metacharacters, spaces, and additional command arguments.

Windows-Specific Vector:

On Windows, the wpopenv() function concatenates command-line arguments without proper quoting. When srcip contains spaces, additional arguments can be appended to the resulting command line. This is a classic unquoted command-line injection pattern where user-supplied data alters the command structure rather than being treated as a single argument.

Root Privilege Context:

All affected scripts execute as root (or equivalent administrative privileges), amplifying the severity of the injection. Successful exploitation means an attacker achieves command execution capabilities within the context of the active response script's execution environment — though "user interaction" is required in terms of triggering the active response rule, and the privileges required to inject the log events are limited (PR:L).

Exploitation Scenarios

Scenario 1: Firewall Rule Argument Injection via srcip

1. Reconnaissance/Target Identification: An attacker identifies a target running Wazuh manager version 4.2.0 through 4.14.6 with active response rules configured to trigger on firewall-related scripts (route-null.c, pf.c, npf.c, etc.).

2. Flaw Trigger: The attacker injects a crafted log event via any source parsable by Wazuh — syslog being a prominent example — containing a malicious srcip value. The value is not a valid IP address but instead a string such as 1.2.3.4; malicious-command or a value containing spaces and additional command arguments.

3. Payload Execution: When the active response rule fires (e.g., a rule blocking a "bad source IP"), the unvalidated srcip string is passed to pfctl/npfctl/ipfw/route/netsh as a command argument. Because the string is not validated as an IP, the additional characters are interpreted as additional arguments or commands — enabling injection of extra arguments that modify firewall behavior, disable protections, or potentially execute arbitrary commands.

4. Post-Exploitation Impact: The attacker can manipulate firewall rules to permit ingress/egress traffic, disable security controls, or execute commands with root privileges on the Wazuh manager host.

Scenario 2: Arbitrary Account Lockout via disable-account.c

1. Reconnaissance: Same target prerequisite — Wazuh manager with active response rule invoking disable-account.c.

2. Flaw Trigger: The attacker injects a log event where dstuser is set to an arbitrary account name (e.g., a legitimately privileged user like admin or a service account).

3. Payload Execution: When the active response rule triggers, disable-account.c receives the attacker-controlled dstuser value. Since validation only excludes "root", the value is passed to passwd/chuser, which locks the specified account.

4. Post-Exploitation Impact: Denial of service — the attacker can lock out arbitrary system accounts, potentially disrupting operations, locking out administrators, or enabling lateral movement by creating predictable lockout states that distract from other malicious activity.

Attack Prerequisites: No public PoC is available; attack chains are inferred from the vulnerability class (CWE-88 — Improper Neutralization of Argument Delimiters in a Command). The attacker requires the ability to inject or craft log events into the Wazuh pipeline (achieved via various log-forwarding mechanisms), and the target must have active response rules configured to process the vulnerable fields.

Impact Assessment

CVSS Analysis: Score 7.1 (High), Vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L

• Attack Vector: Network — exploitation possible over the network via log injection.
• Attack Complexity: Low — no special conditions required beyond the target having active response enabled.
• Privileges Required: Low — attacker needs ability to send/inject log events.
• User Interaction: None — no user action required.
• Scope: Unchanged — impact confined to Wazuh manager host.
• Confidentiality: None (C:N) — no direct data exfiltration vector.
• Integrity: High (I:H) — firewall manipulation, account lockouts, potential command injection as root.
• Availability: Low (A:L) — account lockouts and firewall rule manipulation can degrade availability.

Business Impact:

• Security Operations Disruption: Wazuh is an XDR/SIEM platform; compromise of the manager undermines the entire security monitoring stack for the organization.
• Firewall Integrity: If the Wazuh manager also functions as a network gateway (or shares infrastructure with firewall systems), injected rules can open the network to external attackers.
• Account Availability: Arbitrary account lockout can cause service outages and deny legitimate users access to critical systems.
• Trust Boundary Breach: The Wazuh manager is a trusted security component; its compromise degrades the integrity of all detection and response operations across the organization.

Blast Radius: Any organization running Wazuh 4.2.0 through 4.14.6 with active response rules enabled that process srcip or dstuser fields. The blast radius is largely limited to the Wazuh manager host itself (scope: unchanged), but the security implications are broad given the manager's role in coordinating endpoint protection.

Detection Guidance

Sigma Rule

title: Wazuh Active Response Command Argument Injection Attempt
id: 852963aa-04d1-4f3a-9a2b-3f3e1f0e7c11
status: experimental
description: Detects potentially malicious srcip or dstuser values in Wazuh alerts that may indicate argument injection attempts against active response scripts
author: Valtersit Threat Intelligence
logsource:
    product: wazuh
detection:
    selection_srcip:
        alert.data.srcip|contains:
            - ' '
            - ';'
            - '|'
            - '&'
            - '$('
            - '`'
        alert.data.srcip|re: '^(?!(([0-9]{1,3}\.){3}[0-9]{1,3})|([0-9a-fA-F]{0,4}:){2,7}[0-9a-fA-F]{0,4}$).+'
    selection_dstuser:
        alert.data.dstuser|contains:
            - ' '
            - ';'
            - '|'
            - '&'
            - '$('
            - '`'
    condition: selection_srcip or selection_dstuser
level: high
falsepositives:
    - Legitimate edge-case log formats with unusual but valid field values
    - Internal applications using delimited source identifiers
tags:
    - attack.command_and_control
    - attack.t1059
    - CVE-2026-54085

YARA Rule

rule Wazuh_Active_Response_Arg_Injection {
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects suspicious srcip/dstuser patterns indicative of CVE-2026-54085 exploitation"
        cve = "CVE-2026-54085"
        date = "2026-01-01"
        severity = "high"
    strings:
        $route_nulls = "route-null" nocase
        $netsh = "netsh" nocase
        $pf = "pfctl" nocase
        $npf = "npfctl" nocase
        $ipfw = "ipfw" nocase
        $disable_account = "disable-account" nocase
        $srcip = "srcip" nocase
        $dstuser = "dstuser" nocase
        $metachar1 = " ;" ascii
        $metachar2 = " |" ascii
        $metachar3 = " &&" ascii
        $metachar4 = " $(" ascii
        $metachar5 = " `" ascii
        $space = " " ascii
    condition:
        (any of ($route_nulls, $netsh, $pf, $npf, $ipfw, $disable_account)) and
        (any of ($srcip, $dstuser)) and
        (any of ($metachar1, $metachar2, $metachar3, $metachar4, $metachar5)) and
        (#space > 0)
}

Suricata IDS Rule

alert ip any any -> any any (msg:"Wazuh Active Response Argument Injection Attempt (CVE-2026-54085)"; content:"srcip"; content:"srcip"; content:"route-null"; sid:25408501; rev:1; metadata:cve CVE-2026-54085; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-54085;)

Note: Suricata detection is primarily network-based; since this vulnerability triggers via log event injection (usually over UDP/TCP logging protocols), detection should focus on anomalous log message payloads. Recommended placement: inspect syslog traffic (port 514/udp, 514/tcp) for malformed IP fields or the presence of shell metacharacters within srcip/dstuser values.

Elastic Detection

sequence by host.name with maxspan=30s
  [ process where event.type == "start" and process.name in ("pfctl", "npfctl", "ipfw", "route", "netsh", "passwd", "chuser") and
    process.args : ("*;*", "*|*", "*&&*", "*$(*", "*`*") ]
  [ process where event.type == "start" and process.parent.name in ("wazuh-modulesd", "active-response") ]

Splunk SPL Query

index=wazuh sourcetype="wazuh_alerts"
| where like('alert.data.srcip', "%;%") OR like('alert.data.srcip', "% | %") OR like('alert.data.srcip', "%&&%") OR like('alert.data.srcip', "%,%") OR like('alert.data.dstuser', "%;%") OR like('alert.data.dstuser', "% | %") OR like('alert.data.dstuser', "%&&%")
| rename alert.data.srcip as "Potential_Malicious_SRCIP", alert.data.dstuser as "Potential_Malicious_DSTUSER"
| table _time, agent.id, manager.name, rule.description, "Potential_Malicious_SRCIP", "Potential_Malicious_DSTUSER"
| where NOT match("Potential_Malicious_SRCIP", "^[0-9]{1,3}(\\.[0-9]{1,3}){3}$") 
| where NOT match("Potential_Malicious_SRCIP", "^([0-9a-fA-F]{0,4}:){2,7}[0-9a-fA-F]{0,4}$")
| stats count by _time, manager.name
| sort - _time

Wazuh OSSEC Rule

<group name="wazuh_active_response,attack.command_injection,">
  <rule id="254085" level="12">
    <specific>verification</specific>
    <if_sid>80700</if_sid>
    <match>srcip|dstuser</match>
    <regex>(\;|\||\&\&|\$\(|`)</regex>
    <description>Potential argument injection in active response script input (CVE-2026-54085)</description>
    <mitre id="1059" />
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 (UNPATCHED) — no patch evidence from any tracked source as of this report. The NVD description confirms a fix in version 4.14.7, but the vendor advisory and patch artifacts have not yet been verified through tracked channels.

Immediate Mitigations (apply without delay):

1. Disable affected active response scripts: If feasible, temporarily disable the route-null, netsh, pf, npf, ipfw, and disable-account active response scripts from production Wazuh managers until patched.
2. Restrict log ingestion sources: Implement allowlists for syslog-forwarding sources — accept log events only from known, trusted infrastructure to reduce the ability of external attackers to inject crafted events.
3. Harden syslog exposure: Restrict network access to syslog ingestion ports (514/udp, 514/tcp, 5514/tcp for Wazuh) by source IP; place behind a firewall that only permits known log forwarders.
4. Input validation layer: If custom integrations are possible, add an intermediate processing layer that validates srcip (must be valid IPv4/IPv6) and dstuser (alphanumeric only, whitespace-stripped) before handing off to active response.
5. Alert field sanitization: Configure Wazuh decoders to sanitize or reject alerts containing shell metacharacters in srcip and dstuser fields at decode time.
6. Monitor active response execution: Add logging/monitoring around the execution of pfctl, npfctl, ipfw, route, netsh, passwd, and chuser to detect unexpected arguments.

Patch/Upgrade Steps:

1. Test the patched version (4.14.7) in a non-production environment that mirrors your deployment (same agents, active response rules, and log sources).
2. Upgrade the Wazuh manager to version 4.14.7 in a staged rollout — upgrade test instances first, validate active response functionality, then promote to production.
3. Confirm the upgrade preserves existing configuration (all active response scripts, rules, and decoders). Validate that the five srcip-handling scripts now invoke get_ip_version() and that disable-account.c includes proper dstuser validation.
4. Document the upgrade in change management with rollback procedures.

Long-Term Hardening:

1. Principle of least privilege: Review whether active response scripts must execute as root. Consider removing or replacing scripts that can be re-implemented with minimal privilege or delegated to dedicated service accounts.
2. Input validation at every trust boundary: Implement centralized validation for all fields that flow from log ingestion to system command execution. Define strict schemas for alert fields (srcip as IP, dstuser as domain user format).
3. Secure syslog deployment: Mandate authenticated log transport (TLS with client certificates) to prevent spoofed log events from reaching the Wazuh parser.
4. Review active response rule triggers: Audit rules for over-broad trigger conditions; reduce the attack surface by ensuring only high-confidence alerts trigger active responses.
5. Command whitelisting: If supported by the active response framework, whitelist permissible command arguments — reject any argument not matching strict IP/user patterns.
6. Continuous audit: Re-evaluate this CVE after patch availability; verify mitigation effectiveness through penetration testing of the active response pipeline.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-54085 — Official NVD record, CVSS 7.1, CWE-88.
2. Wazuh Official Advisories (pending): https://documentation.wazuh.com/current/release-notes/release-4-14-7.html — Version 4.14.7 release notes confirming the fix.
3. CWE-88 – Improper Neutralization of Argument Delimiters in a Command: https://cwe.mitre.org/data/definitions/88.html — Vulnerability class reference for argument injection.
4. MITRE ATT&CK – Command and Scripting Interpreter (T1059): https://attack.mitre.org/techniques/T1059/ — Technique mapping for command execution via injection.
5. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE-2026-54085 is not listed in KEV at the time of writing; no known exploit-in-the-wild campaigns have been publicly tracked.

No threat actor campaigns or exploit-in-the-wild evidence have been reported for this CVE as of this writing. The attack chain presented is inferred from the vulnerability class and the specific technical details in the NVD description.