Wazuh from 4.1.1 before 4.14.8 contains a path traversal vulnerability in the getlistfile helper that allows malicious cluster workers to read arbitrary files via unvalidated filename values. Attackers holding the cluster key can send DistributedAPI requests with traversal filenames to read client.keys, ossec.conf with the cluster key, and other wazuh-readable files.

Wazuh from 4.0.0 before 4.14.8 contains a race condition in API login throttling that allows unauthenticated attackers to bypass maxloginattempts by sending concurrent requests. Attackers can fire concurrent login bursts to the authenticate and runas endpoints, each passing the block check before failures are counted, enabling unlimited password guessing.

Wazuh from 4.0.0 before 4.14.8 contains an information disclosure vulnerability that allows low-privileged users with agent:read to retrieve the plaintext authd.pass enrollment password via the unmasked agent configuration endpoint. Attackers holding the default readonly role can request the auth component configuration for pseudo-agent ID 000 to obtain the secret and enroll rogue agents against the manager.

Wazuh from 3.12.0 before 4.14.8 contains a heap buffer overflow in fimgeneratealert() where fulllog is sized from input but written bounded by OSMAXSTR. An enrolled agent can send a crafted FIM syscheck event to corrupt manager heap memory and deterministically crash wazuh-analysisd, causing a fleet-wide detection outage.

Wazuh 4.14.3 before 4.14.8 and 4.10.4 contains a case-sensitivity mismatch between the ossec.conf validator and wazuh-logcollector that bypasses remote-command validation. Authenticated users with manager:updateconfig can inject an uppercase LOGFORMAT command localfile that the collector runs as root on reload.

Wazuh from 4.1.1 before 4.14.8 contains a path traversal vulnerability in uploadlistfile, uploadrulefile, and uploaddecoderfile that allows malicious cluster workers to write files at arbitrary paths. Attackers holding the cluster key can send DistributedAPI requests with ../ sequences in filename, bypassing REST controller validation, to write files as the wazuh user.

Wazuh versions from 3.9.0 before 4.14.8 contain an arbitrary file overwrite vulnerability in MasterHandler.processfilesfromworker allowing a cluster worker to overwrite protected master files. Attackers controlling a worker can use a trailing-slash basename bypass and missing extravalid enforcement to overwrite ossec.conf and agent.conf, achieving root remote code execution across the manager and every agent.

Wazuh from 4.3.0 before 4.14.8 contains a remote code execution vulnerability where SCA policy trust is determined by file path rather than configuration source. Attackers controlling a manager can write unsigned policy files to var/incoming via the upgrade channel and reference them to execute command checks as root on agents.

Wazuh 4.0.0 before 4.14.8 fails to invalidate issued tokens for runas users with zero static roles, because checktoken never consults the blacklist. Attackers with revoked administrator grants can continue authenticating and self-link the administrator role to permanently retain privileged access.

Wazuh from 4.1.0 before 4.14.8 contains a missing origin check in wmagentupgrade that allows enrolled agents to issue upgradecustom commands with attacker-controlled filepath. Attackers can inject an upgradecustom message over the agent channel to read arbitrary files as root, exfiltrating /etc/shadow and client.keys.

Wazuh versions from 4.6.0 before 4.14.8 contain an authentication bypass vulnerability where security.updateuser places the reserved user guard and password policy inside a falsy truthiness check. A delegated user administrator can send an empty password to the user update endpoint, bypassing the reserved user guard to take over the wazuh superuser account and authenticate with empty credentials.

Wazuh from 4.1.1 before 4.14.8 contains a path traversal vulnerability in the getlists() and deletelistfile() CDB list handlers that allows compromised cluster workers to read or delete master files. Attackers can send traversal or absolute-path filenames through the internal cluster RPC path, bypassing REST validation and RBAC to delete files like rbac.db.

Wazuh from 4.1.1 before 4.14.8 contains a path traversal vulnerability in the deleterulefile and deletedecoderfile helpers that allows malicious cluster workers to delete arbitrary files via an unvalidated filename parameter. Attackers holding the cluster key can invoke these helpers through DistributedAPI with traversal sequences to delete ossec.conf, client.keys, or rules as the wazuh user.

Wazuh from 4.0.0 before 4.14.8 contains an authorization bypass vulnerability that allows low-privileged authenticated users to read the RBAC catalog by querying unprotected security endpoints. Attackers can request GET /security/actions and /security/resources, which omit the caller's RBAC policies, to map privileged actions and endpoints for privilege escalation planning.

Wazuh from 3.9.0 before 4.14.8 contains an uncontrolled YAML alias expansion vulnerability in yaml2jsonnode that allows a manager-controlled policy to exhaust agent memory. Attackers controlling the manager can push a small SCA policy with nested aliases via merged.mg to OOM-kill wazuh-modulesd on every agent in a group.

Wazuh is an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. From 3.9.0 until 4.14.7, wazuh-clusterd in framework/wazuh/core/cluster/common.py allocates a payload buffer using the size declared in a 20-byte cluster protocol header before Fernet decryption validates the peer. An unauthenticated network peer can declare a payload of up to 256 MiB, stop sending after the header, and retain that allocation until the TCP connection closes. The cluster listener has no application-level per-source connection budget in affected versions, allowing concurrent sockets to multiply memory consumption and potentially terminate the cluster process, disrupt synchronization, and interrupt distributed API forwarding. 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. From 3.8.0 until 4.14.7, the getattributes() function in src/osxml/osxml.c recursively processes every XML attribute without a depth limit while allocating two large local buffers in each stack frame. An enrolled agent can submit a Windows EventChannel event containing an element with enough attributes to exhaust the analysisd worker-thread stack, trigger a segmentation fault, and interrupt log ingestion. The element-depth limit in ReadElem() does not constrain the number of attributes on one element, so it does not prevent this condition. 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, 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 an open-source security platform providing unified XDR and SIEM protection for endpoints and cloud workloads. In versions 4.2.0 through 4.14.6, multiple active response scripts pass attacker-influenced alert fields to privileged system commands without validating their format, allowing argument injection into tools that run as root. Five of the eight scripts that handle the srcip field, route-null.c, netsh.c, pf.c, npf.c, and ipfw.c, omit the getipversion() check that rejects non-IP input, and disable-account.c passes the dstuser field to passwd/chuser with only a comparison against "root". An attacker who can inject crafted log events, for example via syslog, can supply srcip or dstuser values that, when an active response rule triggers, are passed unvalidated to firewall and account-management commands such as pfctl, npfctl, ipfw, route, netsh, and passwd. This enables injecting additional command arguments, and on Windows the unquoted CreateProcess command-line concatenation in wpopenv() lets a srcip containing spaces add further arguments, while disable-account.c can be abused to lock arbitrary system accounts. 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. The  ip-customblock  active response script contains a path traversal vulnerability that lets an attacker create or delete arbitrary files on the filesystem as root. The script builds a file path by concatenating the  srcip  field taken from alert JSON directly onto the fixed  /ipblock/  base directory, without validating that the value is a well-formed IP address. Because the extraction routine returns the raw string unchecked, an attacker who can trigger alert-matching log events with a crafted  srcip  containing  ../  sequences can escape the base directory. The block action opens the resulting path in append mode, creating an empty file at an arbitrary location, while the unblock action passes it to remove(), deleting an arbitrary file; since the active response daemon runs as root, this includes sensitive files such as system credentials and Wazuh configuration. Unlike the sibling scripts host-deny.c, default-firewall-drop.c, and firewalld-drop.c, which reject non-IP input via getipversion(), ip-customblock.c omits this validation. 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.