If your estate runs Wazuh Manager in the 4.14.3 to 4.14.7 range, the decision is straightforward: move to 4.14.8 or later. INCIBE-CERT published INCIBE-2026-753 on 16 October 2026 describing CVE-2026-74041, a critical flaw that allows an authenticated user with the manager:update_config permission to reach root command execution through a case-sensitivity mismatch in how ossec.conf is validated and interpreted.
What follows is a practical sequence for teams that need to close the gap quickly and prove afterwards that they did.
Step 1: Establish the inventory
Query the deployed version of every manager instance. The vulnerable range begins at 4.14.3 inclusive and stops before 4.14.8. Instances below 4.14.3 are outside the stated range for this CVE, and instances at 4.14.8 or above already contain the remedy.
Record version, host, environment and owner for each instance. Managers frequently sit in pairs or clusters, and a partial upgrade leaves the cluster in a mixed state worth documenting.
Step 2: Understand what you are closing
The flaw is not a missing check. A validator exists for remote commands in ossec.conf. A separate component, wazuh-logcollector, then reads the same file. Case handling differs between the two, so a LOG_FORMAT directive written in upper case slips past the validator's command filtering while remaining meaningful to the collector.
The command runs as root when the manager reloads. That is the mechanism in the advisory: a configuration permission becomes operating-system privilege.
Step 3: Schedule the upgrade
Upgrade to 4.14.8 or later, following the vendor's normal upgrade path for your deployment model. Plan a maintenance window if your cluster cannot roll without interruption. Back up configuration and state before the change, as with any manager upgrade.
After the upgrade, confirm the reported version on every node rather than assuming the package manager did what the plan intended.
Step 4: Compensate while the window is open
For instances that cannot be patched immediately, reduce the number of identities holding manager:update_config to the smallest workable set and review that set against job function. Treat the permission as root-equivalent for the duration.
Inspect ossec.conf for LOG_FORMAT directives and for any entry whose casing departs from the documented form. Correlate unexpected entries with change records. This is detection and hygiene; it does not remove the underlying parsing inconsistency.
Step 5: Check the logs you already have
A reload follows any successful attempt, which makes reload auditing valuable. Look for configuration changes followed by service restarts outside change windows, and for LOG_FORMAT content introduced by accounts that normally do not touch logging directives.
The advisory does not describe attacker tooling or indicators of compromise, so these checks are inference from the documented mechanism rather than published detection signatures.
Scope at a glance
Product: Wazuh Manager.
Vulnerable versions: 4.14.3 up to, but not including, 4.14.8.
Severity: critical, importance 5 in the INCIBE rating.
CVE: CVE-2026-74041.
Advisory: INCIBE-2026-753, 16 October 2026.
Exploitation recorded at publication: none.
Reading the exposure data correctly
A ZoomEye query for app="Wazuh" returned 18031 matching assets when checked for this article. The paired CVE filter, vul.cve="CVE-2026-74041", returned zero.
The first number tells you how many internet-facing services present a Wazuh fingerprint. It does not tell you how many run a vulnerable build. The second tells you what the index has tagged with this identifier, and absence there is not absence of risk. Version determination belongs to an asset owner with access to the Host.
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 query records from 2026-10-22:
app="Wazuh"(18031),vul.cve="CVE-2026-74041"(0).