Act nowDisclosed

Advisory · CVE-2026-74041

Case mismatch in Wazuh config validation lets a manager user run root commands

Wazuh 4.14.3 through the releases before 4.14.8 validate remote commands case-sensitively in one component and not in another, so an authenticated manager user can smuggle a command entry that logcollector later runs as root. CVSS 3.1 9.1.

Advisory published October 13, 2026Independent summary
Vendor
Wazuh
Product
Wazuh manager
Identifier / CWE
CVE-2026-74041
CWE-178
Action timing
Immediate
ELI5

Explain it like I’m five

One Wazuh component reads configuration in lowercase only, the other accepts shouting. Writing a setting in uppercase sails past the checker and still gets executed by the component that runs it.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Manager access

    An attacker with the manager update_config permission edits ossec.conf.

  2. 02Uppercase entry planted

    The attacker adds a localfile entry whose command format is written in uppercase, which the validator does not flag.

  3. 03Collector reloads

    On reload, wazuh-logcollector treats the entry as a remote command definition.

  4. 04Root command runs

    The collector executes the attacker's command with root privileges.

What happened

Wazuh disclosed CVE-2026-74041 for the manager in 4.14.3 through the releases before 4.14.8. The ossec.conf validator and wazuh-logcollector disagree on case sensitivity for a command-format setting, so an entry the validator treats as harmless is later honored as a command by the collector, which runs as root on reload.

The vendor’s affected data marks 4.14.8 as the first unaffected release, so upgrading the manager to 4.14.8 or later is the stated fix.

What to do

  1. Inventory every Wazuh manager deployment, including test, training, and individually managed instances.
  2. Apply the vendor fix or upgrade exactly as directed in the linked vendor bulletin or advisory.
  3. Restrict network access to Wazuh manager while remediation is underway, especially for internet-facing instances.
  4. Review application and server logs for uppercase or mixed-case command-format entries in ossec.conf, recent configuration changes by manager users, and unexpected child processes of the log collector.
  5. Check for accounts, content, or configuration created outside normal change processes, and rotate exposed credentials where access cannot be ruled out.
  6. Verify the deployed version or patch level after remediation.

Management note

This turns a configuration permission into root on the security manager itself. Patch, then audit who changed manager configuration recently.