CVE-2026-44901: Wazuh Platform RCE Vulnerability

CVE-2026-44901 Overview

CVE-2026-44901 is a code injection vulnerability in Wazuh, an open-source threat prevention, detection, and response platform. The flaw affects versions 4.0.0 through 4.14.5 and the 5.0.0-beta1 pre-release. The AffectedItemsWazuhResult.merge() method in framework/wazuh/core/results.py trusts the sort_casting field returned by cluster worker nodes without validating type names against an allowlist. A compromised worker can supply exec as a type name and Python source in affected_items, causing the master node to execute the payload as root during distributed API response merging. The issue is tracked under [CWE-502] and resolved in versions 4.14.6 and 5.0.0-beta2.

Critical Impact
A compromised Wazuh cluster worker can achieve remote code execution as root on the master node by injecting a malicious sort_casting value during a distributed API merge.

Affected Products

Wazuh 4.0.0 through 4.14.5
Wazuh 5.0.0-beta1
Wazuh cluster deployments using distributed API merges

Discovery Timeline

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

Technical Details for CVE-2026-44901

Vulnerability Analysis

Wazuh operates in a master-worker cluster architecture. When an API request spans multiple nodes, the master merges JSON responses from workers using AffectedItemsWazuhResult.merge(). The merge routine reads the sort_casting field from each worker response and resolves the supplied type names through Python builtins. Because no allowlist is enforced, any callable in builtins becomes reachable, including exec and eval. When the resolved callable is applied to attacker-controlled data from affected_items, arbitrary Python code executes in the master process. Wazuh services run as root by default, so successful exploitation yields full host compromise.

Root Cause

The root cause is unsafe type resolution during JSON deserialization [CWE-502]. The merge() method treated worker-supplied strings as trusted type identifiers and dispatched them through Python's dynamic name resolution. No structural validation confirmed that sort_casting contained only primitive casting types such as int, float, str, or bool. The trust boundary between worker and master was implicit rather than enforced in code.

Attack Vector

Exploitation requires an attacker to control or compromise a Wazuh cluster worker node. This restricts the attack to the adjacent network with high privileges on a worker. Once positioned, the attacker crafts a JSON response setting sort_casting to ['exec'] and places Python source in affected_items. When the master initiates a distributed API call and merges the response, the payload runs as root on the master, escalating a single-node compromise into cluster-wide control.

python

         AbstractWazuhResult
             Instance of AbstractWazuhResult.
         """
+        ALLOWED_TYPES = {'int', 'float', 'str', 'bool'}
+        sort_casting = obj.get('sort_casting', ['int'])
+        if not isinstance(sort_casting, list):
+            raise wexception.WazuhInternalError(1000, extra_message="sort_casting must be a list")
+
+        for type_name in sort_casting:
+            if not isinstance(type_name, str):
+                raise wexception.WazuhInternalError(1000, extra_message=f"sort_casting type must be a string, got {type(type_name).__name__}")
+            if type_name not in ALLOWED_TYPES:
+                raise wexception.WazuhInternalError(1000, extra_message=f"Invalid sort_casting type '{type_name}'. "
+                                                                         f"Allowed types: {', '.join(sorted(ALLOWED_TYPES))}")
+
         result = cls()
         result.affected_items = obj['affected_items']
         result.sort_fields = obj['sort_fields']
-        result.sort_casting = obj['sort_casting']
+        result.sort_casting = sort_casting
         result.sort_ascending = obj['sort_ascending']
         result.total_affected_items = obj['total_affected_items']
         result.dikt = obj['dikt']

Source: Wazuh commit b29849f8. The patch enforces an allowlist of primitive types and rejects any other value in sort_casting.

Detection Methods for CVE-2026-44901

Indicators of Compromise

Wazuh master processes spawning unexpected child processes such as sh, bash, python, or curl shortly after cluster API requests.
Cluster worker responses containing sort_casting values other than int, float, str, or bool.
New or modified files under Wazuh installation directories originating from the master node without administrator action.
Outbound network connections from the Wazuh master to previously unseen destinations.

Detection Strategies

Inspect cluster inter-node traffic for JSON payloads where sort_casting contains callable names such as exec, eval, compile, or __import__.
Alert on Python code strings appearing inside affected_items fields of worker responses.
Correlate WazuhInternalError code 1000 messages with the extra message referencing sort_casting after upgrading, which indicates blocked exploitation attempts.

Monitoring Recommendations

Enable process ancestry logging for the Wazuh master service and alert on non-standard descendants of wazuh-apid and wazuh-clusterd.
Baseline the outbound network profile of the master node and flag deviations.
Forward Wazuh cluster logs and Linux audit records to a central SIEM for retention and cross-node correlation.

How to Mitigate CVE-2026-44901

Immediate Actions Required

Upgrade all Wazuh cluster nodes to version 4.14.6 or 5.0.0-beta2 as documented in the GitHub Security Advisory GHSA-8c6v-7g3w-prrq.
Audit every worker node for signs of compromise before completing the upgrade, since a single trusted worker enables master takeover.
Rotate Wazuh cluster keys and any credentials accessible from the master after patching.

Patch Information

The fix is delivered in Wazuh v4.14.6 and v5.0.0-beta2. The patch in commit b29849f8 validates the sort_casting field against the allowlist {'int', 'float', 'str', 'bool'} and raises WazuhInternalError on any other value. Additional context is available in pull request #35757.

Workarounds

Restrict the cluster network so only trusted, hardened hosts can act as workers, and block direct external access to worker nodes.
Enforce mutual TLS and strong key management for inter-node communication until upgrades are complete.
Run the Wazuh master under a dedicated, unprivileged service account where operational requirements allow, to limit the impact of code execution.

bash

# Verify Wazuh version on every cluster node before and after upgrade
/var/ossec/bin/wazuh-control info | grep WAZUH_VERSION

# Upgrade example on Debian/Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade wazuh-manager=4.14.6-1

# Confirm the cluster is healthy after upgrading all nodes
/var/ossec/bin/cluster_control -l