Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Per Wazuh's Security Policy, vulnerabilities affecting only non-GA versions are not eligible for a CVE ID.

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. There is a buffer overflow hazard in wazuh-analysisd when handling Unicode characters from Windows Eventchannel messages. It impacts Wazuh Manager 3.8.0 and above. This vulnerability is fixed in Wazuh Manager 4.7.2.

In the wazuh-slack active response script in Wazuh 4.2.x before 4.2.5, untrusted user agents are passed to a curl command line, potentially resulting in remote code execution.

Improper input validation in the Wazuh agent for Windows prior to version 4.8.0 allows an attacker with control over the Wazuh server or agent key to configure the agent to connect to a malicious UNC path. This results in the leakage of the machine account NetNTLMv2 hash, which can be relayed for remote code execution or used to escalate privileges to SYSTEM via AD CS certificate forging and other similar attacks.

Wazuh workflows before 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 GITHUBTOKEN and AWS credentials on self-hosted runners.

Wazuh is a free and open source platform used for threat prevention, detection, and response. Prior to version 4.13.0, a vulnerability in Wazuh Agent allows authenticated attackers to force NTLM authentication through malicious UNC paths in various agent configuration settings, potentially leading NTLM relay attacks that would result privilege escalation and remote code execution. This issue has been patched in version 4.13.0.

Wazuh is a free and open source platform used for threat prevention, detection, and response. Starting in version 3.9.0 and prior to version 4.14.3, a privilege escalation vulnerability exists in the Wazuh Manager's cluster synchronization protocol. The wazuh-clusterd service allows authenticated nodes to write arbitrary files to the manager’s file system with the permissions of the wazuh system user. Due to insecure default permissions, the wazuh user has write access to the manager's main configuration file (/var/ossec/etc/ossec.conf). By leveraging the cluster protocol to overwrite ossec.conf, an attacker can inject a malicious <localfile> command block. The wazuh-logcollector service, which runs as root, parses this configuration and executes the injected command. This chain allows an attacker with cluster credentials to gain full Root Remote Code Execution, violating the principle of least privilege and bypassing the intended security model. Version 4.14.3 fixes the issue.

Wazuh is a free and open source platform used for threat prevention, detection, and response. Versions 4.0.0 through 4.14.2 have a Remote Code Execution (RCE) vulnerability due to Deserialization of Untrusted Data). All Wazuh deployments using cluster mode (master/worker architecture) and any organization with a compromised worker node (e.g., through initial access, insider threat, or supply chain attack) are impacted. An attacker who gains access to a worker node (through any means) can achieve full RCE on the master node with root privileges. Version 4.14.3 fixes the issue.

Wazuh is a free and open source platform used for threat prevention, detection, and response. Prior to version 4.14.5, issues in the Cluster Distributed API (DAPI) handling allow a cluster peer, or any actor able to authenticate to the cluster channel using the shared cluster key, to make the master node deserialize an attacker-controlled callable and execute it under an attacker-controlled RBAC context. The cluster code in framework/wazuh/core/cluster/common.py deserializes JSON with aswazuhobject(), which resolves any callable whose top-level package is wazuh or api (an overly broad allowlist controlled only by ALLOWEDCALLABLESPACKAGES), and DAPI requests handled in framework/wazuh/core/cluster/dapi/dapi.py accept a client-supplied rbacpermissions value that runlocal() applies as the global RBAC context, so supplying an rbacmode of black causes authorization checks for exposeresources-protected functions to pass without any legitimate permission assignment. Combined, these allow privileged administrative actions on the master node such as arbitrary file writes under WAZUHPATH, creation of new API users, and tampering with security.yaml, and can be chained into full manager compromise. This issue has been fixed in version 4.14.5.

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-beta3, cluster.unmergeinfo() in framework/wazuh/core/cluster/cluster.py constructs paths from peer-controlled mergetype and name values in a merged synchronization archive. processfilesfromworker() 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 filesmetadata.json or a merged-file header to write files such as /var/ossec/etc/ossec.conf. Replacing ossec.conf can configure root-executed commands and lead to code execution when Wazuh services reload. This issue is fixed in versions 4.14.6 and 5.0.0-beta3.

Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.3.0 until 4.14.6 and 5.0.0-beta3, the non-merged branch of processfilesfromworker() in framework/wazuh/core/cluster/master.py trusts a peer-controlled filepath key from filesmetadata.json. The destination is joined to WAZUHPATH without proving that it remains inside the directory selected by clusteritemkey. 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. Replacing ossec.conf can configure root-executed commands and lead to code execution after a service reload. This issue is fixed in versions 4.14.6 and 5.0.0-beta3.

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-beta3, DistributedAPI.sendtmpfile() in framework/wazuh/core/cluster/dapi/dapi.py joins an attacker-controlled tmpfile value to WAZUHPATH 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/privatekey.pem allows the peer to forge administrator REST API tokens offline and then exercise administrative privileges without creating an account. This issue is fixed in versions 4.14.6 and 5.0.0-beta3.

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.

Wazuh is a free and open source platform used for threat prevention, detection, and response. A wrong validation in the hostdeny script allows to write any string in the hosts.deny file, which can end in an arbitrary command execution on the target system. This vulnerability is part of the active response feature, which can automatically triggers actions in response to alerts. By default, active responses are limited to a set of pre defined executables. This is enforced by only allowing executables stored under /var/ossec/active-response/bin to be run as an active response. However, the /var/ossec/active-response/bin/hostdeny can be exploited. hostdeny is used to add IP address to the /etc/hosts.deny file to block incoming connections on a service level by using TCP wrappers. Attacker can inject arbitrary command into the /etc/hosts.deny file and execute arbitrary command by using the spawn directive. The active response can be triggered by writing events either to the local execd queue on server or to the ar queue which forwards the events to agents. So, it can leads to LPE on server as root and RCE on agent as root. This vulnerability is fixed in 4.7.2.

Wazuh is a security detection, visibility, and compliance open source project. In versions 4.4.0 and 4.4.1, it is possible to get the Wazuh API administrator key used by the Dashboard using the browser development tools. This allows a logged user to the dashboard to become administrator of the API, even if their dashboard role is not. Version 4.4.2 contains a fix. There are no known workarounds.

Wazuh API in Wazuh from 4.0.0 to 4.0.3 allows authenticated users to execute arbitrary code with administrative privileges via /manager/files URI. An authenticated user to the service may exploit incomplete input validation on the /manager/files API to inject arbitrary code within the API service script.

Wazuh v3.6.1 - v3.13.5, v4.0.0 - v4.2.7, and v4.3.0 - v4.3.7 were discovered to contain an authenticated remote code execution (RCE) vulnerability via the Active Response endpoint.

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, AffectedItemsWazuhResult.merge() in framework/wazuh/core/results.py trusts the sortcasting field in a cluster worker's JSON response. During a distributed API merge, attacker-controlled type names are resolved through Python builtins without an allowlist. A compromised worker can set sortcasting to exec and place Python source in affecteditems, causing the master to execute the payload as root when responses from multiple nodes are merged. This issue is fixed in versions 4.14.6 and 5.0.0-beta2.

Wazuh version 4.12.0 contains an exposure vulnerability in GitHub Actions workflow artifacts that allows attackers to extract the GITHUBTOKEN 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. From version 4.8.0 to before version 4.14.4, a stack-based buffer overflow exists in printhexstring() in wazuh-remoted. The bug is triggered when formatting attacker-controlled bytes using sprintf(dstbuf + 2i, "%.2x", srcbuf[i]) on platforms where char is treated as signed and the compiled code sign-extends bytes before the variadic call. For input bytes such as 0xFF, the formatting can emit "ffffffff" (8 chars) instead of "ff" (2 chars), causing an out-of-bounds write past a fixed 2049-byte stack buffer. The vulnerable path is reachable remotely prior to any agent authentication/registration logic via TCP/1514 when an oversized length prefix causes the “unexpected message (hex)” diagnostic path to run. Additionally, the same unauthenticated oversized-message diagnostic path logs an attacker-controlled hex dump to /var/ossec/logs/ossec.log for each trigger, allowing remote log amplification that can degrade monitoring fidelity and consume disk/I/O. This log amplification is reachable even without triggering the sign-extension overflow (e.g., using bytes < 0x80). 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. From 4.9.0 until 4.10.4 and 4.14.6, PUT /security/users/{userid} in api/api/controllers/securitycontroller.py passes request.get("user") instead of request.context['tokeninfo']['sub'] as currentuser. removenonestodict() removes the resulting None value, so the reserved-account protection in framework/wazuh/security.py cannot verify who is making the request. An authenticated user with the usersadmin role can overwrite the password of protected administrator accounts with user IDs at or below 99, including the wazuh superuser, and gain full administrative control. This issue is fixed in versions 4.10.4 and 4.14.6.

Wazuh is a free and open source platform used for threat prevention, detection, and response. A heap-based out-of-bounds WRITE occurs in decodewinpermissions, resulting in writing a NULL byte 2 bytes before the start of the buffer allocated to decodedit. A compromised agent can potentially leverage this issue to perform remote code execution, by sending a specially crafted message to the wazuh manager. An attacker who is able to craft and send an agent message to the wazuh manager can leverage this issue to potentially achieve remote code execution on the wazuh manager (the exploitability of this vulnerability depends on the specifics of the respective heap allocator). This vulnerability is fixed in 4.10.2.

Wazuh is a free and open source platform used for threat prevention, detection, and response. It is capable of protecting workloads across on-premises, virtualized, containerized, and cloud-based environments. This vulnerability occurs when the system has weak privilege access, that allows an attacker to do privilege escalation. In this case the attacker is able to view agent list on Wazuh dashboard with no privilege access. This issue has been addressed in release version 4.9.1 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Wazuh is a free and open source platform used for threat prevention, detection, and response. This bug introduced a stack overflow hazard that could allow a local privilege escalation. This vulnerability was patched in version 4.5.3.

Wazuh is a free and open source platform used for threat prevention, detection, and response. It is capable of protecting workloads across on-premises, virtualized, containerized, and cloud-based environments. The wazuh-agent for Windows is vulnerable to a Local Privilege Escalation vulnerability due to improper ACL of the non-default installation directory. A local malicious user could potentially exploit this vulnerability by placing one of the many DLL that are loaded and not present on the system in the installation folder of the agent OR by replacing the service executable binary itself with a malicious one. The root cause is an improper ACL applied on the installation folder when a non-default installation path is specified (e.g,: C:\wazuh). Many DLLs are loaded from the installation folder and by creating a malicious DLLs that exports the functions of a legit one (and that is not found on the system where the agent is installed, such as rsync.dll) it is possible to escalate privileges from a low-privileged user and obtain code execution under the context of NT AUTHORITY\SYSTEM. This issue has been addressed in version 4.9.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Wazuh is a free and open source platform used for threat prevention, detection, and response. Versions 4.6.0 and above prior to 4.14.5 contain a heap-based buffer overflow vulnerability in the syscheck component of the Wazuh agent for Windows. When expanding registry paths containing wildcards ( or ?), the agent allocates a fixed-size heap buffer of 256 bytes (OSSIZE256). By creating a registry subkey with a maximum allowed length (255 characters) inside a monitored path, a low-privileged local attacker can force an out-of-bounds write during string concatenation. Since wazuh-agent.exe runs as NT AUTHORITY\SYSTEM, this can lead to a silent Denial of Service (blinding the agent) or potentially Local Privilege Escalation (LPE). This issue has been fixed in version 4.14.5.

The agent in OSSEC through 3.1.0 on Windows allows local users to gain NT AUTHORITY\SYSTEM access via Directory Traversal by leveraging full access to the associated OSSEC server.

Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.0.0 until 4.14.5, Wazuh Manager allows a low-privilege read-only API user with manager:read permission to retrieve the cluster key from the element in ossec.conf through GET /manager/configuration?raw=true. An attacker with network access to TCP port 1516 can use the disclosed Fernet key to impersonate a cluster worker and submit distributed API requests containing attacker-controlled rbacpermissions with rbacmode set to black. Because the master trusts the worker-supplied authorization context, the attacker can create users, assign administrator roles, access credentials and API tokens, modify configuration, and execute actions across agents. This issue is fixed in version 4.14.5.