Loading vulnerability…
CVE-2026-25770 is a privilege escalation vulnerability in Wazuh Manager affecting versions 3.9.0 through 4.14.2. The flaw resides in the cluster synchronization protocol implemented by the wazuh-clusterd service, which permits authenticated cluster nodes to write arbitrary files to the manager file system with the privileges of the wazuh system user. Because the default file permissions allow the wazuh user to modify the main manager configuration, an attacker can overwrite the Wazuh configuration and inject a malicious command-bearing <localfile> block. When wazuh-logcollector, which runs as root, later parses the modified configuration, it executes the attacker-controlled command. This creates a privilege escalation chain from cluster-level authenticated file write access to root-level remote code execution on the manager.
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.
wazuh service context to full root code execution on the Wazuh manager. This can result in complete compromise of the security monitoring infrastructure, including modification of configuration, suppression or manipulation of detections, tampering with logs, persistence through configuration abuse, and broader control over connected monitoring operations.If you can’t patch tonight, do this now.
localfile directives. As a defense-in-depth measure, review and harden filesystem permissions on sensitive Wazuh configuration files to reduce the ability of the wazuh user to modify root-consumed configuration.Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
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.
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.
8 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
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.