Loading vulnerability…
CVE-2026-25769 is a critical remote code execution vulnerability in Wazuh cluster-mode deployments affecting versions 4.0.0 through 4.14.2. The flaw is caused by deserialization of untrusted data in the cluster communication path, specifically in the as_wazuh_object function used during JSON deserialization for DAPI messages. The vulnerable logic permits attacker-controlled input to influence module import and callable resolution, allowing crafted cluster messages to cause execution of arbitrary Python callables on the master node. In practice, an attacker who has compromised or otherwise obtained control of a trusted worker node can send a malicious DAPI request to the master and achieve code execution in the master’s processing context. Because the master commonly runs with elevated privileges, successful exploitation can result in root-level command execution and full compromise of the Wazuh cluster control plane.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos (2 hidden).
This repository is a functional proof-of-concept for exploiting two Wazuh cluster vulnerabilities, identified as CVE-2026-255769 and CVE-2026-255770. It is not part of a larger exploit framework. The repo contains 8 files: a Docker Compose lab, master/worker Wazuh cluster configs, a Python exploit, a simple attacker HTTP server, two malicious ossec.conf payloads, and a README explaining the attack chain. The main exploit logic is in scripts/poc.py. That script dynamically loads Wazuh's LocalClient from /var/ossec/framework/wazuh/core/cluster/local_client.py, connects to the local worker cluster client, and sends a crafted DAPI request. The JSON payload abuses the vulnerable as_wazuh_object() behavior by specifying __module__='subprocess' and __name__='getoutput', causing the master to import subprocess and invoke getoutput on attacker-controlled shell commands. The hardcoded command instructs the master to fetch a malicious configuration from an attacker HTTP server at http://172.23.80.1:2709/ossec.conf, save it as /var/ossec/etc/ossec.conf, and restart Wazuh with /var/ossec/bin/wazuh-control restart. A commented alternative command exfiltrates the current configuration to the same HTTP server via POST. The second stage is represented by scripts/ossec.conf and scripts/ossec2.conf. These are malicious Wazuh configuration files that abuse <localfile> with <log_format>command</log_format> and <command> directives. One template contains a reverse shell command using /bin/bash and /dev/tcp/<ip>/<port>; the other runs simple proof commands and writes output to /tmp/log.sam. Once the master loads one of these configs, it repeatedly executes the embedded command according to the configured frequency. scripts/app.py is attacker infrastructure rather than the exploit trigger itself. It starts a Python HTTP server bound to 172.23.80.1:2709, supports POST uploads to capture exfiltrated configuration into ossec_recibido.conf, and serves files over GET so the master can download a malicious ossec.conf. The Docker lab in docker-compose.yaml provisions two Wazuh 4.14.0 manager containers: a master at 172.28.0.10 and a worker at 172.28.0.11. The master publishes cluster port 1516 on 172.23.80.1:1516. master.xml and worker.xml configure the cluster with shared key material, node roles, and peer name wazuh-master. This setup demonstrates the intended trust boundary: a worker can communicate with the master over the cluster protocol and trigger the vulnerable deserialization path. Overall, the repository's purpose is to demonstrate worker-to-master remote code execution in a Wazuh cluster and a follow-on persistence/command-execution technique via malicious configuration overwrite. The exploit is operational because it includes a complete lab, a working DAPI payload, attacker HTTP infrastructure, and ready-to-use malicious configuration files.
This repository is a small standalone proof-of-concept exploit for CVE-2026-25769, an insecure deserialization issue in Wazuh Cluster that can lead to remote code execution on the Wazuh master. The repository contains five files: a README, a Docker Compose lab definition, two Wazuh cluster configuration XML files for master and worker nodes, and the main exploit script at exploit/poc.py. The exploit logic is entirely in exploit/poc.py. It dynamically imports Wazuh's local cluster client from /var/ossec/framework/wazuh/core/cluster/local_client.py, starts that client, and sends a crafted JSON payload over the Wazuh dapi/local_master path. The payload abuses a deserialized __callable__ structure to resolve subprocess.getoutput and passes attacker-controlled shell text in f_kwargs.cmd. As a result, the vulnerable Wazuh component executes arbitrary shell commands on the local master. This is a real exploit, not just a detector, and it supports arbitrary operator-supplied commands via the --cmd argument. The included docker-compose.yml plus master.xml and worker.xml form a reproducible lab environment using wazuh/wazuh-manager:4.9.2 containers. The lab defines a master at 172.28.0.10 and a worker at 172.28.0.11, with cluster communications on TCP/1516 and remote service on TCP/1514. Both cluster configs use the hostname wazuh-master and a shared static cluster key. These files are for demonstration/setup rather than exploitation logic, but they clearly show the intended target topology: a worker-originated request reaching the master through Wazuh cluster mechanisms. Overall, the repository’s purpose is to demonstrate command execution against vulnerable Wazuh versions earlier than 4.14.1 by abusing the cluster local_master request handling and insecure callable deserialization.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Referenced only as related reading; no vulnerability details are discussed in this content.
Referenced only as related reading; no substantive discussion in the content.
A critical remote code execution vulnerability in Wazuh's cluster communication protocol caused by unsafe deserialization in as_wazuh_object(), allowing a compromised worker node to execute arbitrary Python callables and gain root-level code execution on the master node.
A critical remote code execution vulnerability in Wazuh cluster communication caused by unsafe JSON deserialization that allows a compromised worker node to execute arbitrary code on the master node.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.