Permission models in security platforms often grant configuration rights generously. Administrators rotate rules, adjust logging and tune pipelines, so configuration access looks like an editing privilege. CVE-2026-74041 shows the gap between that intuition and reality in Wazuh Manager 4.14.3 through 4.14.7: a holder of manager:update_config can reach root command execution on the manager host.

INCIBE-CERT published the advisory as INCIBE-2026-753 on 16 October 2026 with a critical rating. The flaw is a case-handling mismatch between the ossec.conf validator and the wazuh-logcollector component. An upper-case LOG_FORMAT directive escapes remote command validation and executes as root when the service reloads.

The privilege escalation, stated plainly

Configuration write access is not supposed to be shell access. In this instance it is.

The account must be authenticated and hold manager:update_config. That is the only stated precondition besides the reload. There is no unauthenticated path, no network position requirement and no need to persuade a second party to act. Someone who can edit configuration can plant a directive and wait for the restart that operations will perform anyway.

What the permission actually governs

ossec.conf is not a cosmetic settings file. It directs collectors, defines what gets forwarded and contains directives with command semantics. Any component that turns configuration text into executed commands converts configuration authority into process authority.

The validator exists because someone recognised that risk. The bypass exists because the validator and the interpreter disagreed about a string. A control implemented in the wrong place produces an illusion of safety, which is worse than a documented absence of control because it discourages scrutiny.

Consequences for the platform

Root on a Wazuh Manager affects more than one host. The manager maintains the rule set, receives telemetry from agents and can dispatch active-response actions. Control of that process is control over the monitoring fabric. The advisory documents the root execution; it does not document observed post-exploitation behaviour, and readers should not assume intrusion reports that do not exist.

Redesigning the permission boundary

Three changes follow directly from the advisory.

First, classify manager:update_config as tier zero. Treat holders the way you treat holders of domain administration or hypervisor console access: named individual accounts, documented justification, periodic review and alerting on use.

Second, separate the ability to view configuration from the ability to commit it. Where the product allows it, route changes through a workflow with a second reviewer. An approved change brings its own audit trail.

Third, monitor reloads as privileged actions. A restart of the manager is the moment a configuration payload becomes executable. Logging who triggered it, and pairing that record with the configuration diff, gives incident responders a usable timeline.

Versions and fix

  • Product: Wazuh Manager.

  • Affected: 4.14.3 inclusive through 4.14.7.

  • Fixed: 4.14.8.

  • Advisory: INCIBE-2026-753, 16 October 2026.

  • CVE: CVE-2026-74041.

Upgrade to 4.14.8 or later. The permission review is worthwhile regardless, because the next configuration-to-code defect in any platform will lean on the same trust assumption.

Exposure reading

ZoomEye returned 18031 assets for app="Wazuh" and zero for vul.cve="CVE-2026-74041" when queried for this article. The first figure counts fingerprinted Wazuh services; the second counts indexed findings for this CVE. Neither measures the number of vulnerable installations, which only version inspection can establish.

Search link: https://www.zoomeye.ai/searchResult?q=YXBwPSJXYXp1aCI%3D

Sources

  • INCIBE-CERT, INCIBE-2026-753: https://www.incibe.es/incibe-cert/alerta-temprana/avisos/gestion-incorrecta-de-mayusculas-y-minusculas-en-wazuh-manager

  • ZoomEye query records, 2026-10-22: app="Wazuh" (18031); vul.cve="CVE-2026-74041" (0).