- Wazuh versions from 4.3.0 before 4.14.8 trust policy files by file path, so an attacker controlling a manager can run commands as root on agents (CVE-2026-74036).
- The score is 7.2 because the attacker needs high privileges first. That assumption is the risk when one manager directs many agents.
- Check your Wazuh version, move to 4.14.8 or later, and review who can administer the manager.
Many security failures share one habit: the system trusted something because of where it was found. A document in the internal mail tray is assumed to be internal. CVE-2026-74036 is an example. It is a flaw in Wazuh, the open-source security monitoring platform. It shows how a trusted control point can become the weakest link.
What the record says
The NIST National Vulnerability Database published the entry on October 13, 2026. It covers Wazuh from version 4.3.0 up to, but not including, 4.14.8. The entry describes a remote code execution flaw. That means an attacker can make another machine run commands of the attacker's choosing.
The condition is control of a Wazuh manager, the central server that directs the monitoring software on other machines, called agents. With that control, an attacker can make agents carry out command checks with root rights. Root is the highest level of access on a Linux system. The entry lists a GitHub release for v4.14.8 and a project security advisory among its references.
How the flaw works
Wazuh uses SCA policies. These are policy files that can include command checks, which are instructions an agent runs on its own machine. A policy that can run commands needs strong trust rules.
According to the NVD record, Wazuh decided whether to trust a policy by its file path. It did not check the configuration source. A file in the right folder was treated as trusted.
Here is the path the record describes. The manager's upgrade channel can place policy files, with no signature, in a folder named var/incoming. The attacker then points to those files. Agents treat them as trusted and run the command checks as root.
The lesson here is that a location is not a credential. A signature proves who made a file. A folder name proves only where the file landed. When code can run with full privileges, the check should ask who vouches for it.
Why a 7.2 deserves a closer look
VulnCheck scored the flaw 7.2 (HIGH) under CVSS 3.1. It scored it 8.6 (HIGH) under CVSS 4.0. Both vectors list the privileges required as high. In plain terms, the attacker must already control the manager.
That requirement lowers the score. It does not remove the risk. A manager is the point from which agents take instructions. If an attacker gets there, this flaw turns that foothold into root-level command execution on the agents. The impact ratings for confidentiality, integrity and availability are all high.
The record does not say whether anyone has exploited the flaw. It is based on the NVD entry and the references it lists. We did not review the advisory text.
What leaders should ask
First, ask the team which Wazuh versions run in your environment, on managers and on agents. Anything from 4.3.0 up to, but not including, 4.14.8 is in the affected range. The fix is in 4.14.8.
Second, ask who can administer or write to the manager. The score assumes high privileges, so access to the manager is the control that matters most. Ask how that access is protected and logged.
Third, ask whether agents are expected to run unsigned policy content. If the answer is no, ask how your team would detect it.
A tool that watches your systems can also push commands to them. Treat the machine in charge with the care you give the systems it manages. A folder name should never be the only thing standing between a file and root.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
