Am I vulnerable?
CVE-2026-30893 affects Wazuh, the open-source SIEM/XDR platform, in multi-node cluster deployments. The flaw is in the cluster synchronization extraction routine (decompress_files()): a path-traversal weakness lets an authenticated cluster peer write arbitrary files onto other cluster nodes, which escalates to remote code execution by overwriting a Python module Wazuh loads. The unsettling part is not the mechanism. It is the victim: this is your security-monitoring platform compromising itself, node to node.
This is not an internet-facing pre-auth break. The attacker must reach the cluster plane as a peer, via a compromised worker node, a leaked cluster key, or a rogue node on the cluster network. Treat it as a lateral-movement and blast-radius amplifier, where one foothold reaches the whole Wazuh fleet.
Affected versions
| Product |
Vulnerable range |
Fixed in |
| Wazuh (manager / cluster) |
4.4.0 ≤ version < 4.14.4 |
4.14.4 |
Diagnostic checks (read-only)
- Version:
/var/ossec/bin/wazuh-control info, or read /var/ossec/etc/VERSION[.json], or rpm -q wazuh-manager / dpkg -l | grep wazuh-manager. Anything from 4.4.0 through 4.14.3 is vulnerable.
- Is clustering actually enabled?: inspect the
<cluster> block in /var/ossec/etc/ossec.conf for <disabled>no</disabled> and more than one node in <nodes>. A single-node or disabled cluster removes the authenticated-peer attack surface, but still patch.
- Who can reach the cluster port?: default is 1516/tcp. Run
ss -ltnp | grep 1516 and confirm it is reachable only from trusted manager nodes, not agents or the internet.
- Privilege of the cluster daemon: check whether
wazuh-clusterd runs as root or the wazuh user. Elevated means a successful write becomes system-level host compromise, not just Wazuh-context.
- Post-compromise triage (read-only): integrity-check the Wazuh Python framework tree for recently modified modules, for example
find /var/ossec/framework -name '*.py' -newermt '2026-04-29' -printf '%Tc %p\n' 2>/dev/null, and look for any file written outside the cluster's extraction/temp directory.
Vulnerability
Wazuh manager nodes in a cluster keep state in sync by shipping compressed archives between peers. The routine that unpacks a peer's archive, decompress_files(), does not validate that each member path stays inside the intended extraction directory. That is a classic CWE-22 path traversal, compounded by CWE-73 (external control of a file name or path): a malicious peer crafts an archive whose entries contain ../ sequences, and the receiving node writes attacker-controlled bytes anywhere the Wazuh process can write.
The write is escalated to code execution the same way as the Langflow case (CVE-2026-5027), by overwriting a .py module that a Wazuh component imports, except the delivery channel is the internal cluster protocol rather than an HTTP API. NVD scores it CVSS 9.0 (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:H). Two parts of that vector tell the story:
PR:H: the attacker must be an authenticated cluster peer. That is the one meaningful barrier, and it is why this is a post-foothold problem.S:C: scope changed. The vulnerable component on one node writes code onto and executes on other nodes. That cross-node reach is what pushes an "authenticated" bug to critical.
A proof-of-concept exists (referenced in the GHSA as a separate attachment). Where wazuh-clusterd runs with elevated privileges, the impact is full system compromise of the manager tier.
Why it outranks its "needs an authenticated peer" caveat: Wazuh is the thing watching for intrusions. An attacker who lands here can disable rules and decoders, suppress or forge alerts, delete audit trails, and abuse Wazuh's trusted agent-management channel as a fleet-wide distribution point. Compromising the monitor blinds the defender across the entire monitored estate, not just the Wazuh hosts.
Threat model
Who would exploit this: an adversary who already has a foothold in the environment and can reach the cluster plane, through a compromised worker node, a leaked or reused cluster <key>, or the ability to stand up a rogue node on the cluster network. Realistic operators are ransomware crews and intrusion sets doing post-exploitation who recognize that owning the SIEM buys them blindness and reach. This is lateral movement, not initial access.
What they're after:
- Code execution on the Wazuh manager(s), the highest-value host in the security stack
- Blind the defender: disable rules/decoders, suppress or falsify alerts, wipe local audit trails
- Abuse Wazuh's trusted position. It manages agents across the estate, making a manager foothold a fleet-wide command-and-distribution channel.
- Full host compromise and network pivot where the cluster daemon runs as root
Attack chain: obtain a cluster-peer position (compromised node, stolen cluster key, or rogue node), send a crafted sync archive containing ../ traversal entries, and the target node's decompress_files() writes an attacker .py over a module Wazuh imports. That module executes in the Wazuh service context on the target node(s), and the attacker establishes persistence, tampers with monitoring, and pivots.
Blast radius: scope-changed by design, so a single peer compromises the rest of the cluster. Taking over the SIEM/XDR undermines detection and response for every asset it monitors, and on root-run cluster daemons it is full system compromise of the manager tier.
Mitigation
Patch
Upgrade all Wazuh managers/cluster nodes to 4.14.4 or later. Patch the whole cluster in one pass, because a single unpatched node that can be made (or impersonated as) a peer reintroduces the exposure.
| Product |
Fixed version |
Notes |
| Wazuh |
4.14.4 |
Fixes path validation in decompress_files() (GHSA-m8rw-v4f6-8787) |
Compensating controls
- Guard the cluster key. The
<key> in the <cluster> config authenticates peers, so treat it as a high-value secret, rotate it, and never reuse it across environments. Its exposure is the precondition for this attack.
- Segment the cluster port (1516/tcp). Allow it only between known manager nodes, and block it from agents, user networks, and the internet.
- Least privilege. Run the cluster daemon as the
wazuh user rather than root, capping the escalation to the Wazuh context instead of the host.
- File-integrity monitoring on Wazuh itself. Alert on any modification of
.py modules under /var/ossec/framework/. Wazuh's own FIM can watch its install tree.
- Control cluster membership. Audit the node list and restrict what can join.
Detection (starter rules, validate before deploying)
Host and cluster signals
The exploit rides the internal cluster-sync protocol, not HTTP, so perimeter and web rules do not apply. The durable signals are host-side:
- A
.py file under /var/ossec/framework/ modified by the cluster process (outside a package upgrade), which is the RCE escalation step.
wazuh-clusterd writing files outside its expected sync/extraction directories.- Cluster logs (
ossec-cluster.log) showing sync from an unknown or new node, or extraction errors and path anomalies during sync.
YARA
Post-write hunt for a dropped or overwritten Python payload in the Wazuh tree (broad heuristic, baseline first):
rule Wazuh_CVE_2026_30893_dropped_py_module_heuristic
{
meta:
description = "Heuristic: suspicious Python content in a Wazuh framework module, possibly written via CVE-2026-30893 cluster path traversal. Validate against a known-good baseline."
reference = "https://github.com/wazuh/wazuh/security/advisories/GHSA-m8rw-v4f6-8787"
cve = "CVE-2026-30893"
strings:
$a1 = "os.system("
$a2 = "subprocess.Popen("
$a3 = "socket.socket("
$a4 = /(reverse|bind)_?shell/ nocase
$a5 = "exec(compile("
condition:
filesize < 100KB and 2 of them
}
Sigma
title: Wazuh Framework Python Module Overwrite (CVE-2026-30893)
id: 8b2c1d4e-6f70-4a91-b3c2-wazuh30893
status: experimental
description: File write/modification of a Wazuh framework Python module, the RCE escalation step of the CVE-2026-30893 cluster path traversal. Baseline legitimate writes (package upgrades) before alerting.
references:
- https://github.com/wazuh/wazuh/security/advisories/GHSA-m8rw-v4f6-8787
logsource:
product: linux
service: auditd
detection:
selection:
type: 'PATH'
name|contains: '/var/ossec/framework/'
name|endswith: '.py'
filter_upgrade:
comm:
- 'dpkg'
- 'rpm'
- 'yum'
- 'apt'
condition: selection and not filter_upgrade
fields:
- name
- comm
- exe
level: high
Rule notes
PR:H means this is not a perimeter problem. The best detections are host-side integrity signals plus cluster-membership anomalies, not network rules.- Legitimate cluster sync does write under Wazuh directories, so scope the auditd rule to the framework Python tree and exclude package-manager processes to keep false positives down.
- Because the victim is your monitoring platform, ship Wazuh's own audit/integrity events to an independent log store. An attacker who lands this can tamper with Wazuh-local logs and alerts.
References