CVE-2026-41424: Wazuh Authentication Bypass Vulnerability

CVE-2026-41424 Overview

CVE-2026-41424 is an authorization bypass vulnerability in Wazuh, an open source platform for threat prevention, detection, and response. The flaw exists in the PUT /security/users/{user_id} endpoint within api/api/controllers/security_controller.py. The controller passes request.get("user") instead of request.context['token_info']['sub'] as the current_user argument. The reserved-account protection in framework/wazuh/security.py therefore cannot verify who is making the request. An authenticated user holding the users_admin role can overwrite the password of any protected administrator account with a user ID at or below 99, including the wazuh superuser.

Critical Impact
An authenticated users_admin user can hijack the wazuh superuser account and obtain full administrative control over the Wazuh deployment.

Affected Products

Wazuh 4.9.0 through 4.10.3
Wazuh 4.11.0 through 4.14.5
Fixed in Wazuh 4.10.4 and 4.14.6

Discovery Timeline

2026-08-19 - CVE-2026-41424 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-41424

Vulnerability Analysis

CVE-2026-41424 is an authorization bypass [CWE-863] in the Wazuh API user-update flow. The vulnerable controller builds f_kwargs for security.update_user with current_user sourced from request.get("user"). That key does not exist on the request object, so the value resolves to None. The helper remove_nones_to_dict() then strips the None entry before the call reaches the security framework.

In framework/wazuh/security.py, the reserved-account guard executes only when current_user is not None. With current_user stripped, the guard is skipped entirely for any target user ID at or below MAX_ID_RESERVED (99). The caller can therefore reset the password of the built-in wazuh superuser and any other reserved admin account. Because the API requires authentication and the users_admin role, the attack vector is authenticated privilege escalation from a delegated user-management role to full platform administrator.

Root Cause

The root cause is an incorrect authorization check driven by unsafe extraction of the caller identity. The controller reads the authenticated principal from an unrelated request key instead of the validated JWT claim at request.context['token_info']['sub']. Combined with remove_nones_to_dict() silently discarding the missing value, the downstream reserved-account check has no identity to evaluate and falls through.

Attack Vector

An attacker authenticates to the Wazuh API using any account holding the users_admin role. The attacker issues a PUT /security/users/{user_id} request targeting a reserved ID such as 1 (the wazuh superuser) with a new password. The reserved-account protection is bypassed, the password is overwritten, and the attacker logs in as the superuser.

python

# Patch: api/api/controllers/security_controller.py
 f_kwargs = await UpdateUserModel.get_kwargs(request,
                                             additional_kwargs=
                                             {'user_id': user_id,
-                                              'current_user': request.get("user")})
+                                              'current_user': request.context['token_info']['sub']})

 dapi = DistributedAPI(f=security.update_user,
                       f_kwargs=remove_nones_to_dict(f_kwargs),

Source: Wazuh Commit 1a38d11

python

# Patch: framework/wazuh/security.py
     elif not _user_password.match(password):
         raise WazuhError(5007)

-    if int(user_id[0]) <= MAX_ID_RESERVED and current_user is not None:
+    if int(user_id[0]) <= MAX_ID_RESERVED:
+        if current_user is None:
+            raise WazuhError(5011)
+
         with AuthenticationManager() as auth_manager:
             current_user_id = auth_manager.get_user(current_user)['id']

Source: Wazuh Commit 813add3

Detection Methods for CVE-2026-41424

Indicators of Compromise

PUT /security/users/{user_id} requests where user_id is 99 or lower, especially targeting user ID 1 (the wazuh superuser).
Successful password updates on reserved accounts issued by a caller whose JWT sub claim is not itself a reserved administrator.
Unexpected successful logins to the wazuh account from workstations or IP addresses that previously only used delegated users_admin credentials.

Detection Strategies

Parse Wazuh API access logs for PUT /security/users/ calls and alert when the path parameter resolves to an ID at or below 99.
Correlate password-change events on reserved accounts with the caller identity extracted from the API audit trail.
Baseline which accounts normally administer reserved users and flag deviations, particularly changes originating from non-superuser sessions.

Monitoring Recommendations

Forward Wazuh API and manager logs to a central SIEM and retain them long enough to cover the vulnerable release window (4.9.0 through 4.14.5).
Monitor authentication events for the wazuh account and any other reserved IDs for logins from new source addresses or user agents.
Alert on privilege changes to accounts holding the users_admin role and review the population of that role regularly.

How to Mitigate CVE-2026-41424

Immediate Actions Required

Upgrade Wazuh to 4.10.4 or 4.14.6, which restore the reserved-account guard and read the caller from request.context['token_info']['sub'].
Rotate the password for the wazuh superuser and every reserved account with an ID at or below 99 after upgrading.
Audit the users_admin role membership and remove accounts that do not require user-management privileges.

Patch Information

The fix is delivered in Wazuh 4.10.4 and Wazuh 4.14.6. The corresponding code changes are in Pull Request #35442 and Pull Request #35469. Full technical background is documented in GitHub Security Advisory GHSA-gj9h-8hmr-xjjr.

Workarounds

Restrict the users_admin role to trusted operators until the upgrade is applied, since exploitation requires this role.
Block or reverse-proxy filter PUT requests to /security/users/{user_id} where user_id is at or below 99 if patching cannot be performed immediately.
Enable multi-factor authentication at the reverse proxy in front of the Wazuh API to reduce the risk of stolen users_admin credentials.

bash

# Example: block updates to reserved Wazuh user IDs at an Nginx reverse proxy
location ~ ^/security/users/([0-9]{1,2})$ {
    if ($request_method = PUT) { return 403; }
    proxy_pass https://wazuh-api-backend;
}