CVE-2026-74041 is a configuration validation bypass in Wazuh Manager versions 4.14.3 through 4.14.7, published by INCIBE-CERT as INCIBE-2026-753 on 16 October 2026 and rated critical. The exploitation path leaves a trail, because it ends in a configuration change followed by a service reload. This article works through what a detection programme can reasonably look for, and where the published advisory stops short.

The mechanism in one paragraph

A validator inspects ossec.conf for remote commands. A separate component, wazuh-logcollector, reads the same file. The two differ in case handling. An authenticated user with the manager:update_config permission writes a LOG_FORMAT directive in upper case, the validator's command filtering does not engage, and the collector still acts on the directive. When the manager reloads, the command runs as root.

What is documented and what is inferred

Documented by the advisory: the affected versions, the permission required, the two components, the directive involved, the root execution on reload, the severity rating, the reporters, and that no exploitation had been recorded at publication.

Not documented: specific log lines, command strings, attacker tooling, or indicators of compromise. Any detection rule built today rests on the mechanism rather than on published signatures, and readers should treat it accordingly.

Building detection from the mechanism

Three observable events make up the chain.

  • A configuration change to ossec.conf performed by an account that does not normally write configuration, or performed outside a change window.

  • Content introduced that includes a LOG_FORMAT directive, particularly with casing that departs from documented examples.

  • A manager reload or restart that follows shortly after the configuration change.

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

Alert design that survives contact with operations

A rule that fires on every LOG_FORMAT occurrence will drown in legitimate tuning. Practical variants:

  1. 1.

    Baseline which accounts write configuration, then alert on deviation from that baseline rather than on the write itself.

  2. 2.

    Alert when a configuration change and a reload occur within a short interval outside an approved window.

  3. 3.

    Alert when configuration content containing LOG_FORMAT differs in casing from the vendor's documented form.

  4. 4.

    Track reload frequency per host; an unexplained increase is worth a look even before configuration content is examined.

None of these replaces the upgrade. They buy time and produce evidence on patched and unpatched estates alike.

The permission question

manager:update_config is the gate. In many deployments a small group holds it, frequently for operational reasons rather than because least privilege was designed. Reviewing who holds it is a vulnerability-management action and, in effect, a detection improvement: fewer legitimate holders means less noise when one of them does something unusual.

Affected versions and remedy

Wazuh Manager 4.14.3 up to, but not including, 4.14.8. The fix is upgrading to 4.14.8 or later. Anything in the affected range should be scheduled, and the schedule should be visible in the same change system that will later provide evidence for these detections.

Exposure figures with the right units

A ZoomEye query for app="Wazuh" matched 18031 assets on 2026-10-22. vul.cve="CVE-2026-74041" matched zero. The first is a count of services presenting a Wazuh fingerprint; the second is a count of index entries tagged with the CVE. Neither states how many hosts run a vulnerable build, and the difference matters when a finding is escalated to management.

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

Sources

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

  • ZoomEye observations, 2026-10-22: app="Wazuh" = 18031, vul.cve="CVE-2026-74041" = 0.