CVE-2026-41424 wazuh CVE debrief

Who should care

Wazuh platform administrators, security teams, and users with the users_admin role should review and apply patches to prevent exploitation. These individuals should assess their exposure, implement compensating controls, and monitor for suspicious activity on user accounts with IDs at or below 99, especially the wazuh superuser account. They should also verify the integrity of user accounts and passwords, and implement additional security measures to detect and prevent unauthorized password changes. Furthermore, they should stay informed about any additional information released by the vendor or security community regarding this vulnerability. Affected operators and security teams must prioritize patching to mitigate potential operational impact. Vulnerability management and security teams should track exceptions, retest remediated assets, and ensure evidence of verification is documented before closing the item. This requires coordination with IT operations and change management processes to ensure timely and effective remediation. Security teams should also review compensating controls for exposed systems while remediation is scheduled and verified. Monitoring and detection capabilities should be reviewed to ensure they can identify potential exploitation attempts or anomalous activity related to user account changes. Asset inventory management is crucial to identify and prioritize affected systems for remediation. Implementing source tracking for changes related to this vulnerability can help in quickly identifying and responding to potential security incidents. Rollback/change windows should be considered for patches to minimize disruption while ensuring security. In summary, a broad range of stakeholders within an organization, from technical teams to management, should be aware of this vulnerability and take appropriate actions to mitigate its impact. This includes not only immediate remediation efforts but also longer-term improvements to vulnerability management and incident response capabilities. The involvement of multiple teams is essential to ensure a comprehensive and effective response to this security issue. The vulnerability's potential impact on

Technical summary

The Wazuh platform has a vulnerability in the PUT /security/users/{user_id} endpoint, allowing authenticated users with the users_admin role to overwrite passwords of protected administrator accounts, including the wazuh superuser. This is due to the incorrect use of request.get('user') instead of request.context['token_info']['sub'] as current_user in api/api/controllers/security_controller.py, bypassing the reserved-account protection in framework/wazuh/security.py. The vulnerability affects Wazuh versions from 4.9.0 until 4.10.4 and 4.14.6, and is fixed in versions 4.10.4 and 4.14.6.

Defensive priority

Authenticated users with the users_admin role can overwrite passwords of protected administrator accounts, including the wazuh superuser, gaining full administrative control.

Recommended defensive actions

• Review and apply patches in versions 4.10.4 and 4.14.6
• Restrict access to PUT /security/users/{user_id} to authorized users
• Monitor for suspicious activity on user accounts with IDs at or below 99
• Implement compensating controls to detect and prevent unauthorized password changes
• Perform an asset inventory to identify and prioritize affected systems for remediation
• Consider rollback/change windows for patches to minimize disruption while ensuring security
• Implement source tracking for changes related to this vulnerability to quickly identify and respond to potential security incidents

Evidence notes

The issue is in PUT /security/users/{user_id} in api/api/controllers/security_controller.py, where request.get('user') is used instead of request.context['token_info']['sub'] as current_user. This allows authenticated users with the users_admin role to overwrite passwords of protected administrator accounts with user IDs at or below 99. The vulnerability affects Wazuh versions from 4.9.0 until 4.10.4 and 4.14.6, and is fixed in versions 4.10.4 and 4.14.6. Evidence is limited to public CVE and NVD information.

Official resources