Critical Wazuh Flaw Lets Authenticated Users Run Root Commands via Config Bypass

Wazuh manager versions before 4.14.8 contain a critical vulnerability that allows authenticated users to bypass remote-command validation. The flaw stems from a case-sensitivity mismatch between the configuration validator and the log collector component.

The National Vulnerability Database records this issue as CVE-2026-74041 with a CVSS score of 9.4, rating it as Critical. The weakness is classified under CWE-178. The description notes a case-sensitivity mismatch between the ossec.conf validator and wazuh-logcollector that bypasses remote-command validation.

Technical Details of the Vulnerability

The vulnerability arises because the ossec.conf validator and wazuh-logcollector handle character casing differently. An authenticated user who possesses the manager:update_config permission can inject a specific command into the configuration. By using an uppercase LOG_FORMAT command within a localfile directive, the attacker can bypass the validation checks.

According to the NVD record, when the configuration is reloaded, the wazuh-logcollector processes this injected command. Because the collector runs with root privileges, the injected command executes as root. This allows an attacker to run commands as root on the system via the collector.

Affected Systems and Scope

Only Wazuh manager instances running versions prior to 4.14.8 are affected by this vulnerability. The issue is specific to the interaction between the configuration validator and the log collector within these older versions. Users running version 4.14.8 or later are not impacted by this specific case-sensitivity mismatch.

The exploitation requires an attacker to already have an authenticated session with specific permissions. The attacker must hold the manager:update_config capability to modify the configuration files. This limits the initial attack surface to users or services that have legitimate administrative access to the Wazuh manager interface.

What should you do?

Security teams should immediately inventory their Wazuh deployments to identify any managers running versions older than 4.14.8. Since the source identifies versions before 4.14.8 as affected, upgrading to 4.14.8 or later resolves the issue. Administrators should also review access logs for any unauthorized configuration changes.