Wazuh 4.4.0 before 4.14.7 contains a denial of service vulnerability in the fdecompressfiles() function within cluster.py that allows authenticated cluster peers to exhaust memory by supplying a malicious synchronization archive without decompressed size limits. Attackers holding a valid cluster Fernet key can upload a small, highly compressed zip bomb archive that forces wazuh-clusterd on the master node to decompress the full payload into memory, causing memory exhaustion and service disruption.
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 an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.4.0 through 4.14.6, a party holding the cluster key can write, overwrite, or delete arbitrary files under /var/ossec on worker nodes, leading to remote code execution as root. During cluster file synchronization, the non-merged branch of updatemasterfilesinworker() moves each staged file to a destination derived only from safejoin(), which confines the path to /var/ossec but never verifies that the file lands in the directory declared by its clusteritemkey. Because the destination check present on the primary node and on the worker's merged branch was not applied, a peer can place files at attacker-chosen locations under /var/ossec, including paths that are executed as root, and the delete branch has the same gap. This is an incomplete fix for CVE-2026-30893, which addressed traversal outside /var/ossec but left this path able to redirect files anywhere within it. This issue is fixed in version 4.14.7.
Summary An unsafe deserialization vulnerability allows for remote code execution on Wazuh servers. 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.
Details DistributedAPI parameters are a serialized as JSON and deserialized using aswazuhobject (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 (unhandledexc) to evaluate arbitrary python code.
Using the server API, it quite easy to trigger. For example, using the runas endpoint (implemented by runaslogin in api/api/controllers/securitycontroller.py): the authcontext argument is completely controlled by the attacker, and is forwarded to the master server to handle. By sending a malicious runas request to a worker server, it is possible to execute code on the master server.
It is also possible to exploit the bug as a compromised agent, in certain configurations. A compromised agent can respond to a getconfig request with a malicious JSON object (containing a serialized unhandled exception). If the getconfig request was caused because of a server API request to /agents/{agentid}/config/{component}/{configuration} (api.controllers.agentcontroller.getagentconfig), and the agent is managed by a server other than the one that received the server API request, the unsafe deserialization will occur on the server that received the original server API request.
user server A server B agent | | | | | -get-config-> | | | | | --get-config-dapi-> | | | | | --getconf-> | | | | <-payload-- | | X <-----payload------ | | | | | |
It is likely that there are more ways to reach the unsafe deserialization function (aswazuhobject), some of them might even be accessible from different contexts (without credentials, or initiated by a compromised agent). I suggest fixing the root cause instead of attempting to sanitize inputs that reach it. Note that there are multiple other ways to execute arbitrary code in aswazuhobject, easier by using a callable, or potentially abusing callable gadgets in exception, wresults or Wazuh.
PoC To trigger using the server API (assuming default credentials): bash curl -X POST -k -u "wazuh-wui:MyS3cr37P450r.-" -H "Content-Type: application/json" --data '{"unhandledexc":{"class": "exit", "args": []}}' https://<worker-server>:55000/security/user/authenticate/runas this will shut down the master server.
Impact This is a remote code execution on Wazuh server, affecting the latest version (v4.9.0 at this time)
Wazuh is a free and open source platform used for threat prevention, detection, and response. From version 4.4.0 to before version 4.14.4, a path traversal vulnerability in Wazuh's cluster synchronization extraction routine allows an authenticated cluster peer to write arbitrary files outside the intended extraction directory on other cluster nodes. This can be escalated to code execution in the Wazuh service context by overwriting Python modules loaded by Wazuh components (proof of concept available as separate attachment). In deployments where the cluster daemon runs with elevated privileges, system-level compromise is possible. This issue has been patched in version 4.14.4.
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.14.3, a stack-based buffer overflow vulnerability exists in the Wazuh Database synchronization module (wdbdeltaevent.c). The SQL query construction logic allows for an integer underflow when calculating the remaining buffer size. This occurs because the code incorrectly aggregates the return value of snprintf. If a specific database synchronization payload exceeds the size of the query buffer (2048 bytes), the size calculation wraps around to a massive integer, effectively removing bounds checking for subsequent writes. This allows an attacker to corrupt the stack, leading to a Denial of Service (DoS) or potentially RCE. Version 4.14.3 fixes the issue.