CVE-2026-46343 Overview
CVE-2026-46343 is a path traversal vulnerability [CWE-22] in Wazuh, an open source threat prevention, detection, and response platform. The flaw resides in WazuhCommon.end_receiving_file() inside framework/wazuh/core/cluster/common.py. A cluster-authenticated node can send a syn_i_w_m_e request with an unknown task_id, triggering a cleanup branch that passes an attacker-controlled filename to os.path.join without canonicalization. Absolute paths and traversal sequences reach the filesystem, letting an attacker delete files outside WAZUH_PATH. Affected versions include 4.0.0 through 4.14.5 and 5.0.0-beta1. Fixes ship in versions 4.14.6 and 5.0.0-beta2.
Critical Impact
A cluster-authenticated attacker can delete ossec.conf, jwt_secret.json, TLS certificates, and ruleset files, disabling the Wazuh manager, invalidating API tokens, and disrupting cluster and API connectivity.
Affected Products
- Wazuh 4.0.0 through 4.14.5
- Wazuh 5.0.0-beta1
- Wazuh manager cluster deployments using framework/wazuh/core/cluster/common.py
Discovery Timeline
- 2026-08-19 - CVE-2026-46343 published to NVD
- 2026-08-19 - Last updated in NVD database
Technical Details for CVE-2026-46343
Vulnerability Analysis
The vulnerability lives in the Wazuh cluster synchronization protocol. When a worker or master node sends a syn_i_w_m_e (sync integrity worker master end) message, the receiving handler parses task_and_file_names into a task_id and a filename. If the task_id is not present in self.sync_tasks, the handler enters a cleanup branch that attempts to remove the referenced file before raising a WazuhClusterError.
The cleanup branch calls os.path.join(common.WAZUH_PATH, filename) and then os.remove() on the result. Because os.path.join returns the second argument unchanged when it is absolute, an attacker can supply /etc/ossec.conf or ../../etc/shadow and target any file the manager process can access. No canonicalization, no confinement, and no allow-list check is performed before deletion.
Root Cause
The root cause is missing path validation on attacker-controlled input in a privileged filesystem operation. The handler trusts the filename component of the cluster message and assumes it resolves inside WAZUH_PATH. Python's os.path.join does not enforce that assumption, and neither os.path.realpath nor a prefix check was applied before calling os.remove.
Attack Vector
Exploitation requires cluster-authenticated access, which corresponds to the high privileges required in the CVSS vector. An attacker with a valid cluster key crafts a syn_i_w_m_e message containing an arbitrary task_id and a target file path. The receiver enters the cleanup branch and deletes the file. Deleting ossec.conf disables the manager on restart. Deleting jwt_secret.json invalidates all issued API tokens. Deleting TLS certificates breaks API and cluster connectivity.
Response message.
"""
task_id, filename = task_and_file_names.split(' ', 1)
+
+ safe_path = os.path.realpath(os.path.join(common.WAZUH_PATH, filename.lstrip("/")))
+
+ if not any(os.path.commonpath([safe_path, root]) == root for root in _ALLOWED_PREFIXES):
+ self.get_logger(logger_tag).error(f"Write path not allowed")
+ raise exception.WazuhClusterError(3027, extra_message=task_id)
+
if task_id not in self.sync_tasks:
- # Remove filename if task_id does not exist, before raising exception.
- if os.path.exists(os.path.join(common.WAZUH_PATH, filename)):
+ if os.path.exists(safe_path):
try:
- os.remove(os.path.join(common.WAZUH_PATH, filename))
+ os.remove(safe_path)
except Exception as e:
- self.get_logger(logger_tag).error(
- f"Attempt to delete file {os.path.join(common.WAZUH_PATH, filename)} failed: {e}")
+ self.get_logger(logger_tag).error(f"Attempt to delete file {safe_path} failed: {e}")
raise exception.WazuhClusterError(3027, extra_message=task_id)
# Set full path to file for task 'task_id' and notify it is ready to be read, so the lock is released.
- self.sync_tasks[task_id].filename = os.path.join(common.WAZUH_PATH, filename)
+ self.sync_tasks[task_id].filename = safe_path
self.sync_tasks[task_id].received_information.set()
return b'ok', b'File correctly received'
Source: Wazuh commit 90d43547. The patch strips leading slashes, resolves the real path with os.path.realpath, and validates the result against an allow-list of prefixes before any file operation.
Detection Methods for CVE-2026-46343
Indicators of Compromise
- Wazuh manager logs containing Attempt to delete file entries pointing to paths outside WAZUH_PATH, such as /etc/, /var/, or paths containing .. sequences.
- Unexpected WazuhClusterError 3027 errors correlated with missing or truncated configuration, certificate, or ruleset files.
- Manager restart failures caused by a missing ossec.conf, or authentication failures across API clients after jwt_secret.json disappears.
Detection Strategies
- Inspect cluster traffic and application logs for syn_i_w_m_e messages whose filename component contains absolute paths or ../ traversal sequences.
- Monitor file integrity on ossec.conf, jwt_secret.json, TLS certificates under etc/sslmanager*, and ruleset directories, and alert on unexpected deletions.
- Baseline the population of cluster nodes and alert when a node authenticates from an unexpected source or issues an anomalous volume of sync errors.
Monitoring Recommendations
- Enable audit logging on the manager filesystem to record unlink and remove syscalls issued by the Wazuh manager process.
- Forward Wazuh cluster logs to a central SIEM and build alerts on repeated WazuhClusterError 3027 events.
- Track version inventory across cluster members and flag any manager still running a Wazuh build prior to 4.14.6 or 5.0.0-beta2.
How to Mitigate CVE-2026-46343
Immediate Actions Required
- Upgrade all Wazuh manager and worker nodes to 4.14.6 or 5.0.0-beta2.
- Rotate the cluster key and any API tokens issued from a potentially compromised manager, then reissue jwt_secret.json.
- Review manager logs since the deployment of any 4.x cluster for evidence of Attempt to delete file messages referencing paths outside WAZUH_PATH.
Patch Information
The fix is delivered in Wazuh v4.14.6 and Wazuh v5.0.0-beta2. The code change is tracked in pull request #36060 and commit 90d43547. See the GitHub Security Advisory GHSA-cqvw-w2rg-327f for coordinated disclosure details.
Workarounds
- Restrict cluster network access using firewall rules so only trusted manager and worker IPs can reach TCP 1516.
- Enforce strict rotation and secrecy of the cluster key, and audit any node that possesses it.
- Deploy host-based file integrity monitoring on ossec.conf, jwt_secret.json, and TLS material to detect deletion attempts before the upgrade completes.
# Verify current Wazuh manager version and upgrade
/var/ossec/bin/wazuh-control info | grep WAZUH_VERSION
# Debian/Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade wazuh-manager=4.14.6-1
# RHEL/CentOS
sudo yum update wazuh-manager-4.14.6-1
# Restart the manager after upgrade
sudo systemctl restart wazuh-manager
# Restrict cluster port to trusted peers only (example with firewalld)
sudo firewall-cmd --permanent --add-rich-rule=\
'rule family="ipv4" source address="10.0.0.0/24" port port="1516" protocol="tcp" accept'
sudo firewall-cmd --reload
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
