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. 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, 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 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. 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.

Wazuh is a free and open source platform used for threat prevention, detection, and response. Starting in version 4.3.0 and prior to version 4.14.3, a Denial of Service (DoS) vulnerability exists in the Wazuh API authentication middleware (middlewares.py). The application uses an asynchronous event loop (Starlette/Asyncio) to call a synchronous function (generatekeypair) that performs blocking disk I/O on every request containing a Bearer token. An unauthenticated remote attacker can exploit this by flooding the API with requests containing invalid Bearer tokens. This forces the single-threaded event loop to pause for file read operations repeatedly, starving the application of CPU resources and potentially preventing it from accepting or processing legitimate connections. Version 4.14.3 fixes the issue.

Wazuh is a free and open source platform used for threat prevention, detection, and response. In versions 1.0.0 and above, prior to 4.14.5, a heap buffer overflow in wazuh-analysisd allows an unauthenticated remote attacker to crash the Wazuh manager's analysis engine, causing complete loss of SIEM alert processing. The attack exploits the default configuration shipped in the official wazuh/wazuh-docker deployment with default configuration. An attacker can enroll with authd without a password to obtain a valid agent ID and encryption key, connect to remoted over the Wazuh agent protocol, and inject rootcheck events containing  {key: value}  patterns longer than 30 bytes that trigger a sprintf overflow of a 30-byte buffer in WJSONParseRootcheck, corrupting the heap and crashing wazuh-analysisd so that all alert processing silently stops while the dashboard and API keep showing stale data.

Wazuh is a free and open source platform used for threat prevention, detection, and response. In versions 4.0.0 through 4.10.3 and 4.11.0 through 4.14.4, a logic flaw affects the Wazuh Manager's enrollment daemon (authd) and synchronization daemon (remoted). The authd process allows agents to select a group during enrollment but does not filter path traversal sequences such as "..." While the manager checks for the group directory using wopendir(), the ".." sequence references the parent directory (/var/ossec/etc), allowing it to pass validation. After the malicious group is accepted and stored in the manager's global database, the remoted process uses this unchecked value to build paths for agent configuration synchronization. As a result, sensitive files from /var/ossec/etc, such as client.keys, ossec.conf, and internal certificates, are included in the agent's shared configuration stream and exposed to the attacker. This issue has been fixed in versions 4.10.4 and 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-beta2, WazuhCommon.endreceivingfile() in framework/wazuh/core/cluster/common.py allows a cluster-authenticated node to delete files outside WAZUHPATH. A syniwme request with an unknown taskid reaches the cleanup branch, where an attacker-controlled filename is passed to os.path.join without canonicalization or confinement. Absolute paths and traversal sequences can therefore target files such as ossec.conf, jwtsecret.json, TLS certificates, and ruleset files that are accessible to the Wazuh manager process. Deletion can disable the manager, invalidate API tokens, or disrupt cluster and API connectivity. 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.5.0 until 4.14.6 and 5.0.0-beta2, comparewazuhversions() in src/shared/versionop.c copies the attacker-controlled enrollment V: field into a 10-byte stack buffer with strncpy() but does not explicitly terminate the buffer. The function is reachable before authentication through wazuh-authd on TCP port 1515 when anonymous TLS enrollment is enabled. A version string of at least nine non-null bytes can cause strchr() and strtok() to read beyond ver2 and can make strtok() write a null byte into adjacent stack memory, allowing a remote denial of service. 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. 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.

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, multiple stack-based buffer overflows exist in the Security Configuration Assessment (SCA) decoder (wazuh-analysisd). The use of sprintf with a floating-point (%lf) format specifier on a fixed-size 128-byte buffer allows a remote attacker to overflow the stack. A specially crafted JSON event can trigger this overflow, leading to a denial of service (crash) or potential RCE on the Wazuh manager. The vulnerability is located in /src/analysisd/decoders/securityconfigurationassessment.c, within the FillScanInfo and FillCheckEventInfo functions. In multiple locations, a 128-byte buffer (char value[OSSIZE128];) is allocated on the stack to hold the string representation of a number from a JSON event. The code checks if the number is an integer or a double. If it's a double, it uses sprintf(value, "%lf", ...) to perform the conversion. This sprintf call is unbounded. If a floating-point number with a large exponent (e.g., 1.0e150) is provided, sprintf will attempt to write its full string representation (a "1" followed by 150 zeros), which is larger than the 128-byte buffer, corrupting the stack. Version 4.14.3 patches the issue.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority as the behavior originates from a documentation-published Active Response example script. Please refer to this advisory ( https://github.com/wazuh/wazuh-documentation/security/advisories/GHSA-46r5-xp98-fpgg ) for further information.

Wazuh wazuh-agent and wazuh-manager versions 2.1.0 before 4.8.0 contain multiple shell injection and untrusted search path vulnerabilities that allow attackers to execute arbitrary commands through various components including logcollector configuration, maild SMTP server tags, and Kaspersky AR script parameters. Attackers can exploit these vulnerabilities by injecting malicious commands through configuration files, SMTP server settings, and custom flags to achieve remote code execution on affected systems.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Wazuh is a free and open source platform used for threat prevention, detection, and response. In versions 4.6.0 and above, prior to 4.14.5, a logic error in CheckRateLimitsMiddleware.dispatch() causes the /events endpoint rate check to unconditionally overwrite the general rate limit result. When the global maxrequestperminute is exceeded, requests to /events still succeed if the events-specific counter (hardcoded 30/min) has not been reached. This allows event injection into analysisd beyond the admin-configured global rate limit. This issue has been fixed in version 4.14.5.

Wazuh 4.0.0 before 4.14.7 and 5.0.0-beta2 contain a denial of service vulnerability that allows authenticated attackers with allowrunas enabled to exhaust CPU resources by submitting arbitrarily deeply nested JSON structures to the POST /security/user/authenticate/runas endpoint. Attackers can repeatedly submit malformed authcontext bodies with unlimited nesting depth to cause the API framework to consume excessive CPU, denying service to all other API consumers.

Wazuh 5.0.0-beta1 (fixed in 5.0.0-beta3) does not validate or override the clustername and clusternode 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 4.0.0 before 4.14.6 contains a path traversal vulnerability that allows unauthenticated remote attackers to cause denial of service by enrolling an agent with a dot-sequence name such as ".." through the enrollment port. Attackers exploit insufficient validation in OSIsValidName() and unsafe path concatenation in deletediff() to resolve the traversal to the parent queue directory, causing its subdirectories to be removed and stopping all Wazuh services requiring manual recovery.

Wazuh 4.0.0 before 4.14.6 contains a path traversal vulnerability that allows authenticated cluster peers to delete arbitrary directory contents by supplying a traversal-shaped node name in the cluster hello payload without validation. Attackers holding a valid cluster Fernet key can craft a malicious node name and disconnect, triggering the master's peer cleanup routine to remove the contents of arbitrary directories within the Wazuh installation path writable by the wazuh user.

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, an authenticated low-privilege user can read the cluster secret from the manager configuration because the logic that masks sensitive values is disabled by any update-config RBAC rule, including an explicit deny. The masksensitiveconfig() decorator applies masking only when hasupdatepermissions() returns false, but that gate treats a user as able to update the config whenever a  manager:updateconfig  or  cluster:updateconfig  rule exists, without ever checking whether the rule's effect is allow or deny. Because a deny rule is stored as a real entry, a read-only account that is hardened by explicitly denying config edits is counted as having update permission, which turns masking off. A single authenticated GET request to the configuration endpoint with  raw=true  then returns the verbatim ossec.conf XML with  cluster.key  in clear, whereas an otherwise identical account without the deny rule sees the value masked. This issue is fixed in version 4.14.7.