CVE-2026-44901 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.0.0 until 4.14.6 and 5.0.0-beta2, AffectedItemsWazuhResult.merge() in framework/wazuh/core/results.py trusts the sort_casting field in a cluster worker's JSON response. During a distributed API merge, attacker-controlled type names are resolved through Python builtins without an allowlist. A compromised worker can set sort_casting to exec and place Python source in affected_items, causing the master to execute the payload as root when responses from multiple nodes are merged. This issue is fixed in versions 4.14.6 and 5.0.0-beta2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
Wazuh serves as a comprehensive open-source platform designed for threat prevention, detection, and response across distributed environments. The vulnerability identified within this system resides specifically in the framework component responsible for handling API responses from cluster workers. In versions ranging from 4.0.0 through 4.14.6 and up to version 5.0.0-beta2, a critical logic flaw exists in the AffectedItemsWazuhResult.merge() method located within the file framework/wazuh/core/results.py. This function is tasked with consolidating data from multiple nodes during distributed API operations, but it fails to adequately validate or sanitize input fields before processing them for execution contexts.
The core technical flaw involves an insecure deserialization and code injection vector related to how the system handles the sort_casting field in JSON responses received from cluster workers. The application trusts this field without implementing a strict allowlist of permitted type names. Instead, it resolves these types through Python builtins dynamically. This architectural decision creates a severe security gap because it allows an attacker who has compromised a worker node to manipulate the data structure sent back to the master node. By setting the sort_casting parameter to exec and embedding malicious Python source code within the affected_items payload, the attacker can bypass standard validation checks that would otherwise prevent arbitrary code execution.
The operational impact of this vulnerability is severe due to the privilege level at which the Wazuh framework typically operates. When the master node merges responses from multiple nodes, it processes the manipulated sort_casting field using Python's exec function. Consequently, any payload injected by a compromised worker is executed with root privileges on the master system. This effectively grants an attacker full control over the central management server if they can compromise even a single agent or worker within the cluster. The ability to execute arbitrary code as root allows for complete takeover of the Wazuh infrastructure, enabling further lateral movement, data exfiltration, and persistence mechanisms that undermine the entire security posture managed by the platform.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code or Script, specifically involving the injection of executable content through trusted but insufficiently validated input fields. From a tactical perspective, this represents an instance of Command Injection via deserialization flaws where the application relies on dynamic type resolution without sufficient constraints. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1059 Command and Scripting Interpreter, as it allows for the execution of arbitrary commands through Python scripts, and potentially T1190 Exploit Public-Facing Application if the API endpoint is accessible from untrusted networks without proper authentication.
To mitigate this risk, organizations running affected versions must immediately upgrade to version 4.14.6 or later, which includes a fix for this logic error. The patch likely involves implementing strict allowlisting of permitted type names for sort_casting and removing the reliance on dynamic resolution through Python builtins without validation. Until upgrading is possible, administrators should ensure that cluster workers are strictly isolated from untrusted networks and that access to the Wazuh API is heavily restricted by strong authentication mechanisms such as mutual TLS or token-based authorization with minimal privileges. Regular auditing of worker node integrity and monitoring for anomalous JSON structures in API responses can also provide early detection indicators for potential exploitation attempts targeting this specific deserialization flaw.