CVE-2026-61802
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk35th percentile - higher than 35% of all known CVEs
Summary
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.
Risk Assessment
Disclosure of the cluster key to an unprivileged account provides the authentication precondition for cluster-peer remote code execution chains, potentially leading to full system compromise.
Recommendation
Immediately update Wazuh to version 4.14.7 or later that includes the fix, and review API access logs for unauthorized reads of cluster configuration.
Other vulnerabilities in Wazuh
See all- CVE-2026-74043Critical
Wazuh from 4.1.1 before 4.14.8 contains a path traversal vulnerability in upload_list_file, upload_rule_file, and upload_decoder_file that allows malicious cluster workers to write files at arbitrary paths. Attackers holding the cluster key can send DistributedAPI requests with ../ sequences in filename, bypassing REST controller validation, to write files as the wazuh user.
- CVE-2026-74040Critical
Wazuh versions from 3.9.0 before 4.14.8 contain an arbitrary file overwrite vulnerability in MasterHandler.process_files_from_worker allowing a cluster worker to overwrite protected master files. Attackers controlling a worker can use a trailing-slash basename bypass and missing extra_valid enforcement to overwrite ossec.conf and agent.conf, achieving root remote code execution across the manager and every agent.
- CVE-2026-61800Critical
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.
- CVE-2026-49441Critical
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.
- CVE-2026-48162Critical
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.
- CVE-2026-48024Critical
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.
- CVE-2026-67308Critical
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.
- CVE-2025-24016CriticalActively exploited
Wazuh is a platform for threat prevention, detection, and response. Starting in version 4.4.0 and prior to 4.9.1, an unsafe deserialization vulnerability allows remote code execution on Wazuh servers. An attacker can inject an unsanitized dictionary in a DAPI request/response to execute arbitrary Python code.
- CVE-2026-93347Medium
Wazuh from 4.1.1 before 4.14.8 contains a path traversal vulnerability in the get_list_file helper that allows malicious cluster workers to read arbitrary files via unvalidated filename values. Attackers holding the cluster key can send DistributedAPI requests with traversal filenames to read client.keys, ossec.conf with the cluster key, and other wazuh-readable files.
- CVE-2026-93346Medium
Wazuh from 4.0.0 before 4.14.8 contains a race condition in API login throttling that allows unauthenticated attackers to bypass max_login_attempts by sending concurrent requests. Attackers can fire concurrent login bursts to the authenticate and run_as endpoints, each passing the block check before failures are counted, enabling unlimited password guessing.
Original NVD description (English source)
Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In 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 REST API provides a masking control, mask_sensitive_config, that redacts sensitive fields such as authd.pass and cluster.key from configuration responses for users who lack update-config permission, and every config-read endpoint carries this decorator except GET /cluster/local/config. That endpoint, backed by read_config_wrapper, is gated only by cluster:read and returns the local node's cluster configuration including the cleartext key, whereas its siblings return the same value masked. As a result, any account with the default readonly or cluster_readonly role, which is explicitly denied update-config precisely so it cannot view secrets, receives the real cluster key. Because the cluster key authenticates and encrypts traffic between cluster nodes, disclosing it to an unprivileged account provides the authentication precondition for the cluster-peer remote code execution chains established by prior advisories. This issue is fixed in version 4.14.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS