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, masksensitiveconfig, 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 readconfigwrapper, 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 clusterreadonly 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.

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

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.0.0 through 4.14.6, a malicious or man-in-the-middle enrollment manager can crash a Wazuh agent during enrollment by returning a malformed key response with fewer than four fields, causing a NULL pointer dereference. The  wenrollmentprocessagentkey()  routine splits the manager-provided key into four space-separated fields but does not verify that all fields are present before passing them to validators. Because OSStrBreak() leaves missing trailing entries as NULL and OSIsValidName() calls strlen() on its argument without a NULL check, a response such as  OSSEC K:'1'  reaches OSIsValidName(NULL) and terminates the agent process. Since Wazuh permits enrollment against an unverified manager when no CA certificate is configured, an attacker operating a rogue manager or intercepting the enrollment flow can deterministically crash agents, resulting in denial of service. This issue is fixed in version 4.14.7.

Wazuh is a free and open source platform used for threat prevention, detection, and response. From 4.6.0 until 4.14.6 and 5.0.0-beta3, DB::getFile() and DB::searchFile() in src/syscheckd/src/db/src/file.cpp concatenate a monitored file path into SQLite row filters. On non-Windows systems, FIMDBCreator::encodeString() does not escape the value. A local user who can create a filename in a File Integrity Monitoring directory can inject a UNION SELECT expression when wazuh-syscheckd processes or deletes that path. The confirmed primitive manipulates SELECT result sets consumed by the FIM code; stacked statements and remote code execution were not demonstrated. 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.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.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. 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.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. From 4.0.0 until 4.14.6 and 5.0.0-beta2, AuthenticationManager.checkuser() in framework/wazuh/rbac/orm.py performs checkpasswordhash() 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.

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.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 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 is a free and open source platform used for threat prevention, detection, and response. From 1.0.0 until 4.14.6 and 5.0.0-beta2, HandleSecureMessage() in src/remoted/secure.c passes a pointer inside its stack buffer to ReadSecMSG(), and src/oscrypto/shared/msgs.c decompresses up to OSMAXSTR bytes at that offset. For an encrypted agent message on TCP port 1514 that expands to 65,536 bytes, oszlibuncompress() writes a terminating null byte beyond the end of the destination buffer. The resulting stack out-of-bounds write in the root-level remoted daemon can crash message processing and disrupt agent communications. 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, 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 3.9.0 until 4.14.5 and 5.0.0-beta2, the Wazuh cluster protocol in framework/wazuh/core/cluster/common.py allows an authenticated cluster node to exhaust memory on the master. The receivestr() method accepts an attacker-controlled total for InBuffer without a maximum, so a newstr command can request a multi-gigabyte bytearray and repeated requests accumulate in instr. The divided-message path also retains flagdivided fragments under unique counters in divmsgbox without a count, aggregate-size, or expiration limit. Exploitation can disrupt agent connectivity and alert processing across the monitored environment. This issue is fixed in versions 4.14.5 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.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.

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

This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Wazuh. An attacker must first obtain the ability to execute low-privileged code on a worker node in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 9.9. The following CVEs are assigned: CVE-2026-44901.

This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Wazuh. An attacker must first obtain the ability to execute low-privileged code on a worker node in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 9.9. The following CVEs are assigned: CVE-2026-28220.

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 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.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. In versions 3.0.0 and above, prior to 4.14.5, a sizet integer underflow in oscrypto/shared/msgs.c:389 allows any enrolled Wazuh agent to crash the wazuh-remoted process on the manager, immediately disconnecting all agents from the manager. A second code path reached by the same underflow may allow heap memory corruption. 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. 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. 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. 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.