CVE-2026-41424

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.

Reviewed through automated stages and approved by a human before publication.