Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.4.0 until 4.14.6 and 5.0.0-beta2, api/api/middlewares.py decodes the Basic authentication username before credential validation and passes it to the access logger without neutralizing control characters. api/api/alogging.py interpolates that value into the plain-text API log. An unauthenticated attacker can include carriage returns or line feeds in the username to forge entries, obscure activity, or poison systems that consume the plain-text audit log. The JSON log format is not affected because JSON serialization escapes these characters. This issue is fixed in versions 4.14.6 and 5.0.0-beta2.
Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.0.0 until 4.14.6 and 5.0.0-beta2, AuthenticationManager.check_user() in framework/wazuh/rbac/orm.py performs check_password_hash() only when the supplied username exists. A nonexistent username returns immediately, while a valid username causes an expensive bcrypt calculation. An unauthenticated remote attacker can compare authentication response times to enumerate valid Wazuh usernames and use that information in subsequent credential attacks. This issue is fixed in versions 4.14.6 and 5.0.0-beta2.
CVE-2026-44254 is a medium severity vulnerability in Wazuh affecting versions from 1.0.0 up to but not including 4.14.6 and from 5.0.0-beta1 up to but not including 5.0.0-beta2. It involves an incorrect calculation of buffer size in the remoted daemon component, leading to a stack out-of-bounds write when processing certain encrypted agent messages. This can cause crashes and disrupt agent communications. The issue is fixed in versions 4.14.6 and 5.0.0-beta2.
CVE-2026-46343 is a path traversal vulnerability in Wazuh versions from 4.0.0 up to but not including 4.14.6 and from 5.0.0-beta1 up to but not including 5.0.0-beta2. It allows a cluster-authenticated node to delete arbitrary files outside the intended directory by exploiting improper handling of file paths in the end_receiving_file() function. This can lead to deletion of critical configuration and secret files, potentially disabling the manager and disrupting cluster and API operations. The issue is fixed in versions 4.14.6 and 5.0.0-beta2.
CVE-2026-44253 is a medium severity vulnerability in Wazuh versions from 3.9.0 up to but not including 4.14.5 and from 5.0.0-beta1 up to but not including 5.0.0-beta2. It allows an authenticated cluster node to cause memory exhaustion on the master node by sending specially crafted requests that allocate excessive memory without limits. This can disrupt agent connectivity and alert processing. The issue is fixed in Wazuh versions 4.14.5 and 5.0.0-beta2.
Wazuh Manager versions from 4.0.0 up to but not including 4.14.5 contain an authorization vulnerability allowing a low-privilege read-only API user to retrieve the cluster key. This key can be used to impersonate a cluster worker and escalate privileges to perform administrative actions. The issue is fixed in version 4.14.5.
Wazuh 5.0.0-beta1 (fixed in 5.0.0-beta3) does not validate or override the cluster_name and cluster_node fields in inventory-sync Start FlatBuffer messages, while validating only the agentid against the authenticated agent identity. This allows a low-privileged enrolled agent to spoof cluster attribution in indexed inventory and vulnerability documents by forging wazuh.cluster.name values and influencing the document _id prefix, potentially tampering with inventory records or, in shared-indexer multi-cluster deployments, poisoning another cluster's records when numeric agent IDs collide.
Wazuh provisioning scripts and Dockerfiles contain an insecure transport vulnerability where curl is invoked with the -k/--insecure flag, disabling SSL/TLS certificate validation. Attackers with network access can perform man-in-the-middle attacks to intercept and modify downloaded dependencies or code during the build process, leading to remote code execution and supply chain compromise.
Wazuh version 4.12.0 contains an exposure vulnerability in GitHub Actions workflow artifacts that allows attackers to extract the GITHUB_TOKEN from uploaded artifacts. Attackers can use the exposed token within a limited time window to perform unauthorized actions such as pushing malicious commits or altering release tags.
Wazuh is a free and open source platform used for threat prevention, detection, and response. Starting in version 4.4.0 and prior to version 4.9.1, an unsafe deserialization vulnerability allows for remote code execution on Wazuh servers. DistributedAPI parameters are a serialized as JSON and deserialized using `as_wazuh_object` (in `framework/wazuh/core/cluster/common.py`). If an attacker manages to inject an unsanitized dictionary in DAPI request/response, they can forge an unhandled exception (`__unhandled_exc__`) to evaluate arbitrary python code. The vulnerability can be triggered by anybody with API access (compromised dashboard or Wazuh servers in the cluster) or, in certain configurations, even by a compromised agent. Version 4.9.1 contains a fix.