CVE-2026-71540

Wazuh versions 4.4.0 through 4.14.6 contain a vulnerability that allows a party holding the cluster key to write, overwrite, or delete arbitrary files under /var/ossec on worker nodes, potentially leading to remote code execution as root. The issue stems from incomplete path verification during cluster file synchronization. This is fixed in version 4.14.7.

In Wazuh from 4.3.0 until 4.14.6 and 5.0.0-beta3, the non-merged branch of process_files_from_worker() in framework/wazuh/core/cluster/master.py trusts a peer-controlled file_path key from files_metadata.json. The destination is joined to WAZUH_PATH without proving that it remains inside the directory selected by cluster_item_key. A cluster peer holding the shared Fernet key can upload a crafted extra-valid archive and overwrite security-sensitive files such as /var/ossec/etc/ossec.conf, leading to code execution after a service reload.

In Wazuh from 4.0.0 until 4.14.6 and 5.0.0-beta3, DistributedAPI.send_tmp_file() in framework/wazuh/core/cluster/dapi/dapi.py joins an attacker-controlled tmp_file value to WAZUH_PATH without canonicalization or confinement. A cluster peer holding the shared Fernet key can use traversal or an absolute path to make the master return any readable file over the cluster channel. Reading /var/ossec/api/configuration/security/private_key.pem allows the peer to forge administrator REST API tokens offline and then exercise administrative privileges without creating an account.

In Wazuh from 4.0.0 until 4.14.6 and 5.0.0-beta3, cluster.unmerge_info() in framework/wazuh/core/cluster/cluster.py constructs paths from peer-controlled merge_type and name values in a merged synchronization archive. process_files_from_worker() in framework/wazuh/core/cluster/master.py does not adequately confine the resulting path to the declared cluster item directory. A cluster peer holding the shared Fernet key can use traversal in files_metadata.json or a merged-file header to write files such as /var/ossec/etc/ossec.conf, leading to code execution when Wazuh services reload.

Wazuh workflows before commit 44bf114 contain a shell injection vulnerability in GitHub Actions that allows attackers to execute arbitrary commands by submitting pull requests with crafted VERSION.json files. Attackers can inject shell metacharacters into environment variables that are directly interpolated into run steps, enabling command execution and exfiltration of secrets including GITHUB_TOKEN and AWS credentials on self-hosted runners.

In Wazuh from 3.8.0 until 4.14.7, the _getattributes() function in src/os_xml/os_xml.c recursively processes every XML attribute without a depth limit while allocating two large local buffers per stack frame. An enrolled agent can submit a Windows EventChannel event with an element containing enough attributes to exhaust the analysisd worker-thread stack, causing a segmentation fault and interrupting log ingestion.

In Wazuh versions 4.14.0 through 4.14.6, a low-privilege API user can read the cleartext cluster key from a configuration endpoint that fails to redact it. The GET /cluster/local/config endpoint returns the local node's cluster configuration including the cleartext key, whereas its siblings return the same value masked. Any account with the default readonly or cluster_readonly role, which is explicitly denied update-config, receives the real cluster key.

Wazuh versions 4.14.0 through 4.14.6 allow an authenticated low-privilege user to read the cluster secret from the manager configuration. This occurs because the masking logic is disabled by any update-config RBAC rule, including an explicit deny.

Wazuh versions 4.2.0 through 4.14.6 have multiple active response scripts that pass attacker-influenced alert fields to privileged system commands without validating their format, allowing argument injection into tools running as root.