Wazuh CVE-2026-41424

Exploitation requires an authenticated session with an account that has been assigned the users_admin role within the target Wazuh deployment; unauthenticated access or standard analyst/read-only roles are insufficient. The attacker must be able to reach the Wazuh API service (typically exposed on HTTPS port 55000) and the target instance must run Wazuh 4.9.0-4.10.3 or 4.11.0-4.14.5. No non-default configuration is required - the flaw exists in the default code path invoked whenever any users_admin account issues a PUT /security/users/{user_id} request, and the exploit succeeds against any user_id value at or below 99 (the MAX_ID_RESERVED constant), covering all built-in protected accounts including the wazuh superuser (ID 1) and wazuh-wui (ID 2). The primary and most meaningful limiting factor is possession of the users_admin role; organizations that enforce least-privilege role assignments and maintain strong credential hygiene for privileged Wazuh accounts face substantially lower realistic exploitation risk than those that have broadly provisioned the role.

The CVSS 3.1 base score of 8.2 with a Changed Scope flag correctly signals the potential to pivot from a privileged-but-restricted role (users_admin) to full superuser control, which is the genuine danger. However, the vendor-supplied impact metrics of C:L/I:L/A:H appear to substantially understate the realized impact: gaining full administrative control over the wazuh superuser account grants unrestricted read and write access to all security telemetry, agent configurations, active-response rules, and integration credentials - an outcome that warrants C:H/I:H treatment rather than C:L/I:L; defenders should note this discrepancy explicitly and assess the practical severity as higher than the numerical score implies. The PR:H metric (users_admin role required) is the most significant constraint on this vulnerability's real-world risk surface, limiting exploitation to accounts that have already been granted elevated Wazuh permissions via insider access, lateral movement, or over-provisioning. Even a mid-sized municipal IT team in gniezno running Wazuh as their primary SIEM should treat this as urgent, however, because the exploitation path is deterministic and requires only a single well-crafted API request once the role is held - AC:L confirms no race conditions or environmental dependencies apply. No EPSS score was supplied in the input data, and the absence of a CISA KEV listing suggests exploitation has not been confirmed at widespread scale; that said, the simplicity of the technique means the window between patch release and targeted exploitation is likely short.

An attacker who has obtained or legitimately holds a Wazuh account with the users_admin role authenticates to the Wazuh REST API and sends a single PUT request to /security/users/1 with an attacker-chosen password string. Because current_user resolves to None and is stripped by remove_nones_to_dict(), the reserved-account protection check is never enforced, and the wazuh superuser's password is silently overwritten with the attacker's value. The attacker then logs in as the wazuh superuser, gaining unrestricted administrative control over all connected agents, detection rules, and active-response configurations across the entire Wazuh deployment. No public exploit code has been identified, but the deterministic, single-request nature of the flaw requires no tooling beyond a standard HTTP client.