Key points
- Wazuh versions 3.9.0 through 4.14.7 are affected by CVE-2026-74040.
- The flaw allows arbitrary file overwrite via a bypass in MasterHandler.
- Attackers can achieve root remote code execution on the manager and agents.
Wazuh manager versions starting from 3.9.0 up to, but not including, 4.14.8 contain a critical security flaw. According to the National Vulnerability Database, this issue is tracked as CVE-2026-74040 and carries a CVSS score of 9.4. The vulnerability exists within the MasterHandler.process_files_from_worker function. This component handles file transfers from cluster workers to the master node. The flaw allows an attacker who has compromised a worker node to overwrite protected configuration files on the master system.
In plain English
The Wazuh security platform uses a cluster architecture where worker nodes send data and files to a central master node. The vulnerability arises because the master node does not properly validate the filenames sent by workers. An attacker can manipulate the basename of a file by adding a trailing slash. This trick bypasses the security checks designed to prevent overwriting sensitive system files. Consequently, the worker can force the master to replace its own configuration files with malicious content.
The background
The primary targets of this overwrite capability are the ossec.conf and agent.conf files. These files control the behavior of the Wazuh manager and its connected agents. By modifying ossec.conf, an attacker can alter how the manager processes data and executes commands. Changing agent.conf allows the attacker to influence the behavior of every agent connected to the manager. The National Vulnerability Database notes that this leads to root-level remote code execution. This means full control over the management infrastructure and all monitored endpoints.
What changes now
Organizations using Wazuh must verify their current version immediately. Any installation running version 3.9.0 through 4.14.7 is vulnerable to this cluster-based attack. The National Vulnerability Database classifies the weakness as CWE-862, indicating a failure to properly restrict operations. There is no mention in the source material of a specific patch version that resolves the issue. Teams should assume that any version before 4.14.8 remains exposed until confirmed otherwise by the vendor. Operational monitoring of cluster worker behavior is advised.
Who needs to act first
Security operations teams should prioritize isolating Wazuh manager instances exposed to untrusted network segments. Focus on environments where cluster workers might interact with external data sources or compromised endpoints. Verify that internal network segmentation strictly controls traffic between worker nodes and the master. Implement rigorous file integrity monitoring on configuration directories to detect unauthorized changes. Review access controls for any automated scripts that modify cluster settings. Prepare incident response plans that account for potential root-level compromise of the management plane.
What to do and how to stay safe: Wazuh
- Audit all Wazuh installations to identify versions earlier than 4.14.8.
- Restrict network access between cluster workers and the master node.
- Monitor file integrity of ossec.conf and agent.conf for unexpected changes.
- Check logs for unusual file transfer activity from worker nodes.
Step-by-step guide: 7 Configuration Errors That Expose Systems to Zero-Day Exploits
General security guidance from the Vuln Post newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which Wazuh versions are affected by CVE-2026-74040?
Versions from 3.9.0 before 4.14.8 are affected by this vulnerability.
What is the severity rating of this vulnerability?
The National Vulnerability Database rates it as Critical with a CVSS score of 9.4.
How do attackers exploit this flaw to gain access?
They use a trailing-slash basename bypass to overwrite master config files.
