Wazuh Manager CVE-2026-74041

Exploitation requires an authenticated principal holding the manager:update_config permission (PR:H) who can submit an ossec.conf change, and depends on the specific localfile log_format=command remote-command feature being reachable through the config-update path. The attacker must supply an uppercase LOG_FORMAT value so the case-sensitive ossec.conf validator fails to flag it while the case-insensitive wazuh-logcollector still executes it as root; execution occurs on the next configuration reload. Limiting factors: no anonymous/unauthenticated access is possible, the account must already have config-update rights, and the affected versions are specifically Wazuh 4.14.3 through 4.14.7 (fixed in 4.14.8).

This is a genuine high-priority issue for Wazuh operators, but its real-world risk is materially gated by the privilege requirement rather than the raw 9.4 score. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N) and the description agree: exploitation is network-reachable and low-complexity, but requires an authenticated principal already holding the manager:update_config permission (PR:H). The severity is driven by the outcome - code execution as root via wazuh-logcollector on config reload - reflected in full VC:H/VI:H/VA:H plus subsequent-system SC:H/SI:H/SA:H, consistent with a privilege-escalation scope change. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis; the flaw was reported by VulnCheck rather than observed in active exploitation. The practical risk is post-authentication privilege escalation: an operator or compromised API credential with config-update rights turning limited management access into root on the manager host. Note the tag 'Authentication Bypass' is misleading - this is a remote-command-validation bypass that requires authentication, not an authentication bypass. Signals are internally consistent (no conflict between CVSS and description), and a vendor patch is confirmed available in v4.14.8.

An authenticated user (or attacker who has stolen API credentials) holding the manager:update_config permission submits an ossec.conf change containing a localfile block with an uppercase LOG_FORMAT value of 'command'. The ossec.conf validator, being case-sensitive, fails to recognize the uppercase form as a remote command and lets it pass, while the case-insensitive wazuh-logcollector executes the embedded command as root on the next configuration reload. No public exploit code is identified at time of analysis, but the technique is straightforward to reproduce from the advisory.