CVE-2026-41424 in Wazuh
Summary
by MITRE • 08/19/2026
Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.9.0 until 4.10.4 and 4.14.6, PUT /security/users/{user_id} in api/api/controllers/security_controller.py passes request.get("user") instead of request.context['token_info']['sub'] as current_user. remove_nones_to_dict() removes the resulting None value, so the reserved-account protection in framework/wazuh/security.py cannot verify who is making the request. An authenticated user with the users_admin role can overwrite the password of protected administrator accounts with user IDs at or below 99, including the wazuh superuser, and gain full administrative control. This issue is fixed in versions 4.10.4 and 4.14.6.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/19/2026
Wazuh serves as a comprehensive open-source platform designed for threat prevention, detection, and response across distributed environments. Within its API architecture, specifically between version 4.9.0 through 4.10.4 and up to 4.14.6, a critical authentication bypass vulnerability exists in the endpoint responsible for updating user security details. The function PUT /security/users/{user_id} located in api/api/controllers/security_controller.py contains a logic flaw where it incorrectly identifies the current authenticated user by retrieving request.get("user") rather than utilizing the authoritative source of identity found in request.context['token_info']['sub']. This discrepancy arises because the former method relies on data that can be manipulated or is not consistently populated during specific API calls, whereas the latter extracts information directly from the validated JSON Web Token context.
The technical consequence of this misidentification becomes apparent when the system processes the user identity through a utility function named remove_nones_to_dict(). This helper function filters out any key-value pairs where the value is None to streamline data structures for database operations or further processing. Because request.get("user") often returns None in the context of this specific API call, it gets stripped from the dictionary before reaching the security validation layer. Consequently, the reserved-account protection mechanism located in framework/wazuh/security.py fails to receive a valid current_user identifier. This failure prevents the system from performing its mandatory check against a list of protected administrator accounts, effectively disabling the safeguard that is designed to prevent unauthorized modifications to high-privilege identities.
The operational impact of this vulnerability is severe, as it allows any authenticated user possessing the users_admin role to escalate privileges and take control of reserved administrative accounts. Specifically, attackers can overwrite the passwords for all administrator accounts with user IDs less than or equal to 99. This range includes critical system accounts such as the wazuh superuser account. By resetting these passwords, an attacker gains full administrative control over the Wazuh manager, which typically provides access to configuration settings, agent management capabilities, and visibility into security events across the entire monitored infrastructure. This level of compromise undermines the integrity of the entire security monitoring platform, allowing for potential data exfiltration, evasion of detection mechanisms, or further lateral movement within the network.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-915 Improper Control of Dynamically-Identified Variables, as it involves manipulating how the system identifies the executing user context. In terms of adversary behavior, this flaw facilitates privilege escalation consistent with MITRE ATT&CK technique T1078 Valid Accounts, where an attacker uses legitimate credentials to gain unauthorized access and subsequently modifies those accounts to maintain persistence or expand their scope of control. The vulnerability highlights a critical failure in input validation and identity verification within the API controller layer, demonstrating how improper handling of request context can bypass security controls designed for high-privilege operations.
To mitigate this risk, organizations must immediately upgrade Wazuh to version 4.10.4 or later, which includes patches that correct the user identification logic by ensuring request.context['token_info']['sub'] is used consistently. Until an upgrade is performed, administrators should enforce strict network segmentation for the API endpoint and apply additional access control lists if possible. Furthermore, implementing multi-factor authentication for all administrative accounts can provide a secondary layer of defense against credential theft or unauthorized password resets. Regular auditing of user account modifications and monitoring for changes to reserved account IDs below 100 is also recommended to detect any potential exploitation attempts in environments where the patch has not yet been applied.