The vulnerability in CVE-2026-41424 is an authorization bypass in Wazuh's user management endpoint, but the root cause isn't a simple missing check — it's a silent data transformation that destroys authorization context between the controller and security layers.
When a request reaches PUT /security/users/{user_id}, the controller retrieves user context via request.get("user"). Under certain conditions — notably when a valid token with the users_admin role is present but the internal user resolution fails — this returns None. The function remove_nones_to_dict() then strips that None from the payload before passing it downstream. What arrives at the reserved-account protection check in framework/wazuh/security.py is a dictionary with no user field at all — not a failed lookup, but an apparently empty context.
The security layer, receiving this sanitized payload, doesn't fail closed. It either skips the reserved-account check or permits the request because the code path assumes authenticated requests carry resolvable user context. The result: an attacker with users_admin role credentials can overwrite reserved system accounts (root, wazuh, admin) without detection.
What makes this architecturally significant is that remove_nones_to_dict() is a utility likely used elsewhere for legitimate purposes — sanitizing API responses, cleaning config payloads — and was never designed with auth middleware in mind. It converts a detectable failure (user context missing) into an undetectable one (user field absent). Neither layer's tests fail: the utility succeeds at its job, the authorization layer fails gracefully but unsafely.
The EPSS score of 0.00336 for an 8.2 CVSS suggests the exploitation path is narrow — specifically, it requires the users_admin role to exist and be assignable. If that role is installed by default, this is a multi-tenant risk. If it's an optional configuration, it's primarily a single-tenant hardening issue. Verify your deployment's default role assignments to determine actual exposure.
For remediation: update to 4.10.4 or 4.14.6 as the vendor recommends. But the deeper question is whether remove_nones_to_dict() should operate in auth-critical paths at all. Audit every call site where this utility sanitizes auth-adjacent payloads. The reserved-account check must explicitly validate that user context exists and is populated — fail closed at the enforcement point, not at the sanitization layer. The pattern that produced this CVE has appeared in Wazuh's CVE history before (CVE-2023-32681, CVE-2024-10913), suggesting the mechanism itself — not just this instance — needs architectural attention.