CVE-2026-25769: Wazuh cluster flaw enables RCE on master

CVE-2026-25769: Wazuh cluster flaw enables remote code execution

CVE-2026-25769 is a critical Wazuh vulnerability that turns trusted cluster communication into a path for remote command execution on the master node. Research from Hakai Security shows that a compromised worker can abuse insecure deserialization in the cluster protocol to execute arbitrary commands on the master, giving attackers a dangerous way to compromise the very platform many organizations rely on for centralized security visibility.

The issue affects Wazuh versions up to 4.14.1. According to the published technical analysis, exploitation requires access to a worker node, which already provides the cluster key and network position needed to reach the master over the internal cluster channel. Once that trust boundary is broken, the attacker can pivot into the center of the monitoring stack.

Why CVE-2026-25769 matters

This is not just another isolated vulnerability in an internal service. Wazuh often sits close to the heart of the security program, collecting logs, coordinating agents, and supporting detection operations across distributed environments. If an attacker can execute commands on the master node, they can tamper with centralized telemetry, weaken monitoring, and potentially use the platform to support further lateral movement.

That risk becomes more serious in environments where cluster trust is treated as implicit and internal services are not protected with strong network segmentation. In those cases, compromise of a single worker may become enough to endanger the whole Wazuh deployment.

The flaw: insecure deserialization in the cluster protocol

At the center of the issue is Wazuh’s as_wazuh_object() function, used as an object_hook during json.loads() when cluster messages are processed. Hakai Security found that this logic accepts user-controlled fields such as __module__, imports arbitrary Python modules, resolves callables dynamically, and returns functions that are later executed without any meaningful allowlist.

In simple terms, the deserialization flow treats attacker-influenced data as if it were trusted instructions.

How the exploit works

1. Compromise a worker node and gain access to the environment already trusted by the master.
2. Craft a malicious DAPI request that defines a callable such as subprocess.getoutput inside the JSON payload.
3. Send the request through the cluster protocol, encrypted with the same Fernet-based trust material the worker legitimately uses.
4. Trigger deserialization on the master, where Wazuh imports the attacker-chosen module and resolves the requested function.
5. Reach execution when the returned callable is invoked with attacker-supplied arguments.

The core problem is not a broken crypto boundary. It is the assumption that authenticated cluster messages are safe to deserialize into executable Python objects.

Example payload structure highlighted by the research:

json
{
  "f": {
    "__callable__": {
      "__name__": "getoutput",
      "__module__": "subprocess",
      "__qualname__": "getoutput"
    }
  },
  "f_kwargs": {
    "cmd": "id > /tmp/RCE_PROOF && date >> /tmp/RCE_PROOF"
  },
  "request_type": "local_master"
}

According to the researchers, successful exploitation can lead to command execution on the master with Wazuh process privileges, creating a serious platform compromise risk even if the initial foothold begins on a worker.

Timeline defenders should know

Why a Wazuh master compromise is strategically important

A compromised master node can become more than a single-server event. The master typically has broad visibility into agents, policies, event flows, and operational security data. In practical terms, attackers who gain command execution there may be able to blind defenders, tamper with evidence, change configurations, or use the monitoring plane to expand their reach.

That makes this issue especially sensitive for teams that depend on Wazuh as part of their incident response and detection workflow. When a monitoring platform is compromised, the reliability of the signals defenders use to make decisions may be damaged at the exact moment accuracy matters most.

Immediate defensive actions

🔴 Patch and exposure reduction

• Upgrade Wazuh to a fixed release as soon as the vendor makes remediation guidance available.
• Identify every Wazuh cluster deployment running versions up to 4.14.1.
• Review whether worker nodes can reach the master only through strictly controlled paths.
• Treat any previously compromised or high-risk worker node as a possible stepping stone to master compromise.

🟠 Detection and validation

• Hunt for unusual DAPI activity or unexpected administrative actions involving cluster communications.
• Review logs for suspicious command execution, module import behavior, or signs that worker-originated requests triggered unexpected actions on the master.
• Inspect the master for unauthorized changes, tampered rules, or evidence that centralized logging integrity has been affected.
• Prioritize containment if a worker node is suspected of compromise, because the trust relationship may already be enough for follow-on exploitation.

🟡 Hardening priorities

• Reduce implicit trust between cluster nodes wherever operationally possible.
• Strengthen authentication handling and validation around internal message parsing.
• Restrict what functions or objects can ever be reconstructed from cluster traffic.
• Isolate the monitoring plane from broader administrative paths to limit blast radius if trust between nodes is abused.

Illustrative hunt query for suspicious process execution on a Linux-based Wazuh master:

bash
grep -R "subprocess\|getoutput\|local_master\|dapi" /var/ossec/logs /var/ossec/framework 2>/dev/null

Bottom line

CVE-2026-25769 shows how quickly internal trust can become an attack path when deserialization logic is allowed to resolve and execute attacker-controlled callables. If an adversary reaches a Wazuh worker node, this flaw can turn that foothold into command execution on the master and put the security monitoring plane itself at risk.

For defenders, the right response is to treat Wazuh cluster trust as a high-value control surface: review worker exposure, patch quickly, validate master integrity, and assume that compromise of a trusted internal node can have wider consequences than traditional perimeter-focused models suggest.

References

1. Hakai Security research blog
2. GitHub advisory GHSA-3gm7-962f-fxw5
3. Hakai Security PoC repository