Act nowDisclosed

Advisory · CVE-2026-74040

Wazuh cluster worker can overwrite manager files and reach root code execution

Wazuh 3.9.0 through the releases before 4.14.8 let a cluster worker overwrite protected manager files such as ossec.conf, which can become root code execution across the manager and its agents. The project rates it CVSS 3.1 9.1.

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

Explain it like I’m five

A worker node that should only report in can slip filenames past the manager and rewrite the manager's own settings files, and those settings are powerful enough to run commands as root.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Compromised worker

    An attacker controls or impersonates a Wazuh cluster worker connected to the manager.

  2. 02Path check bypassed

    The worker sends files whose names use a trailing-slash trick, and the manager skips the extra validation that should have rejected them.

  3. 03Protected files overwritten

    Manager configuration files such as ossec.conf and agent.conf are replaced with attacker-chosen content.

  4. 04Root execution spreads

    The manager and its agents act on the poisoned configuration, giving the attacker root-level execution.

What happened

Wazuh disclosed CVE-2026-74040 for the manager component in releases from 3.9.0 before 4.14.8. The file-handling path that processes files arriving from cluster workers can be steered into overwriting protected manager files, including the main configuration, because a basename check can be bypassed and an extra validation flag is not enforced.

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 unexpected changes to ossec.conf or agent.conf, new active-response or command settings, and worker nodes sending unusual file transfers.
  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

Wazuh managers sit at the center of detection. A worker-to-manager overwrite is a path from one compromised node to the whole fleet, so patch and then review manager configuration history.