CVE-2026-93347: 
Wazuh Server vulnerability analysis and mitigation

CVE-2026-93347 is a path traversal vulnerability in the get_list_file helper of Wazuh's cluster framework that allows malicious cluster workers to read arbitrary files as the wazuh user. It affects Wazuh versions 4.1.1 through 4.14.7 (fixed in 4.14.8) and was disclosed on October 13, 2026. The vulnerability carries a CVSS v3.1 base score of 4.9 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Feedly).

The root cause is CWE-22 (Path Traversal) combined with CWE-73 (External Control of File Name or Path): the get_list_file function in wazuh/cdb_list.py builds a file path from a caller-supplied filename parameter using get_filenames_paths(filename)[0], which internally uses Path(root).rglob(filename). Because rglob does not match ../ patterns, it falls back to a simple join(USER_LISTS_PATH, filename) without any traversal validation, and then opens the resulting path directly with no boundary check. This function is reachable via the cluster callable path (as_wazuh_object -> DistributedAPI(**request)), bypassing the REST controller; a request omitting rbac_permissions inherits the constructor default {'rbac_mode':'black'}, which permits the action. The same class of vulnerability was previously addressed on the upload side (PR #37691) but the read path was not covered (GitHub Advisory).

A compromised or malicious cluster worker holding the cluster key can read arbitrary files accessible to the wazuh OS user, including client.keys (agent authentication keys), ossec.conf (which contains the cluster key itself), API secrets, and any other wazuh-readable file on the manager. Reading the cluster key is the most critical consequence, as it enables an attacker to fully impersonate a legitimate cluster node, potentially facilitating lateral movement across the entire Wazuh cluster. The impact is limited to confidentiality — no integrity or availability impact has been identified (GitHub Advisory).

A proof-of-concept (poc_getlist_read.py) was developed and demonstrated in an isolated 2-node lab environment running Wazuh 4.14.6, confirming the read primitive against sensitive files such as /etc/hostname, ossec.conf, and client.keys. The PoC invokes the framework function directly in-process and was disclosed responsibly — no weaponized or network-delivered exploit has been published. Exploitation requires possession of the cluster key (high privilege precondition), limiting the attack surface to already-trusted cluster participants. No in-the-wild exploitation has been reported, the EPSS score is 0.0, and the vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Obtain the cluster key: The attacker must already possess or have compromised the Wazuh cluster key (e.g., extracted from a previously compromised worker node's ossec.conf).
2. Set up a malicious cluster worker: Configure a Wazuh worker node (or simulate one) using the stolen cluster key to authenticate to the target cluster master.
3. Craft a DistributedAPI request: Invoke the get_list_file framework function via the cluster callable path (as_wazuh_object -> DistributedAPI(**request)), supplying a traversal filename such as ['../../../../etc/hostname'] or ['../../etc/ossec.conf'] in the filename parameter.
4. Bypass RBAC: Omit rbac_permissions from the request so it inherits the default {'rbac_mode':'black'}, which permits the lists:read action without explicit authorization.
5. Read arbitrary files: The unvalidated path resolves to the target file outside USER_LISTS_PATH, and core.cdb_list.get_list_from_file opens and returns its contents — e.g., the cluster key from ossec.conf or agent keys from client.keys (GitHub Advisory).

• Logs: Wazuh API or cluster logs showing get_list_file calls with filenames containing ../ sequences (e.g., ../../../../etc/hostname, ../../etc/ossec.conf, ../../etc/client.keys).
• Logs: Unexpected DistributedAPI requests originating from a worker node targeting the lists:read action with anomalous filename parameters.
• Network: Unusual cluster communication patterns from a worker node, particularly requests that do not correspond to normal synchronization activity.
• File System: Presence of poc_getlist_read.py or similar scripts on cluster nodes that should not have custom Python tooling.
• Process: Unexpected Python processes on worker nodes invoking Wazuh framework internals outside of normal daemon operation (GitHub Advisory).

Upgrade Wazuh Manager to version 4.14.8 or later, which adds source path validation when retrieving CDB list files (PR #37901) and additional path validation when listing and deleting CDB list files (PR #38214), ensuring the resolved path stays within USER_LISTS_PATH before opening. No official configuration-based workaround has been published; the only remediation is upgrading to the patched release. Organizations should also rotate the cluster key and client.keys if there is any suspicion that a cluster worker may have been compromised (Wazuh v4.14.8 Release, GitHub Advisory).

The vulnerability was reported by researcher namd0ng and remediated by Wazuh developer vikman90, as credited in the official GitHub Security Advisory. The advisory notes this is the same class of path traversal as a previously fixed upload-side issue (PR #37691), highlighting a pattern of incomplete fixes in the same code area. No significant broader media coverage or notable social media commentary has been identified at this time (GitHub Advisory).