Wazuh Manager CVE-2026-74041: uppercase LOG_FORMAT bypass leads to root execution

A case-handling gap that ends in root

CVE-2026-74041 is a configuration-validation bypass affecting Wazuh Manager versions 4.14.3 through 4.14.7, according to a dev.to write-up published on 25 October. INCIBE-CERT published the flaw as INCIBE-2026-753 on 16 October 2026 and rated it critical; the post notes that no exploitation had been recorded when the advisory went out.

The mechanism is a disagreement between two components that read the same file. A validator inspects ossec.conf for remote commands, while wazuh-logcollector reads the same configuration separately, and the two handle letter case differently. An authenticated user holding the manager:update_config permission can write a LOG_FORMAT directive in upper case: the validator's command filtering never engages, but the collector still acts on the directive. When the manager next reloads, the command runs as root.

Detection from logs teams already keep

The advisory, as the post summarises it, documents the affected versions, the permission required, the components and directive involved, root execution on reload and the severity rating — but no log lines, command strings, attacker tooling or indicators of compromise. Any detection rule written today therefore rests on the exploitation mechanism rather than published signatures, a caveat the author states plainly.

The chain breaks into three observable events:

• a change to ossec.conf by an account that does not normally write configuration, or made outside a change window
• introduced content containing a LOG_FORMAT directive, particularly with casing that departs from documented examples
• a manager reload or restart shortly after the configuration change

The third event is what converts a suspicious write into an exploitation attempt. Reloads are routine, so their value comes from correlation with the first two rather than from the reload alone.

Alerts designed for real operations

A rule firing on every LOG_FORMAT occurrence would drown in legitimate tuning, the post argues, and it offers four more durable variants:

• baseline which accounts write configuration, then alert on deviation from that baseline rather than on the write itself
• alert when a configuration change and a reload occur within a short interval outside an approved window
• alert when configuration content containing LOG_FORMAT differs in casing from the vendor's documented form
• track reload frequency per host, since an unexplained increase is worth investigating even before configuration content is examined

None of this replaces the upgrade. These rules buy time and produce evidence on patched and unpatched estates alike.

Permissions and the remedy

manager:update_config is the gate. The post observes that in many deployments a small group holds it, often for operational reasons rather than deliberate least-privilege design, and frames reviewing the holder list as both a vulnerability-management step and a detection improvement: fewer legitimate holders means less noise when one of them does something unusual.

The fix is upgrading to Wazuh Manager 4.14.8 or later. Anything in the affected range should be scheduled, and the post suggests the schedule should live in the same change-management system that will later supply the evidence these detections rely on.

Reading the exposure figures correctly

Citing ZoomEye observations from 22 October, the post reports that a query for app="Wazuh" matched 18,031 assets, while a query for vul.cve="CVE-2026-74041" matched zero. Those numbers measure different things: the first counts services presenting a Wazuh fingerprint, the second counts index entries tagged with the CVE. Neither states how many hosts run a vulnerable build, a distinction the author says matters when a finding is escalated to management.

Why it matters

The flaw turns an authenticated configuration write into root command execution inside a product whose job is security monitoring, so a successful abuse compromises the tool that would otherwise detect it. The practical takeaway is that the exploitation path leaves a visible trail: a configuration change followed by a reload, both of which surface in logs most Wazuh deployments already produce. Mechanism-based detections carry the caveat that no real-world indicators exist yet, so teams should expect to refine rules as telemetry emerges, patch to 4.14.8 or later, and trim the manager:update_config holder list to cut both risk and alert noise.