Wazuh vulnerabilities

Wazuh from 4.1.1 before 4.14.8 contains a path traversal vulnerability in the get_list_file 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 max_login_attempts by sending concurrent requests. Attackers can fire concurrent login bursts to the authenticate and run_as 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 fim_generate_alert() where full_log is sized from input but written bounded by OS_MAXSTR. 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.0.0 before 4.14.8 fails to invalidate issued tokens for run_as users with zero static roles, because check_token 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.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 versions from 4.6.0 before 4.14.8 contain an authentication bypass vulnerability where security.update_user 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.0 before 4.14.8 contains a missing origin check in wm_agent_upgrade that allows enrolled agents to issue upgrade_custom commands with attacker-controlled file_path. Attackers can inject an upgrade_custom message over the agent channel to read arbitrary files as root, exfiltrating /etc/shadow and client.keys.

Wazuh from 4.1.1 before 4.14.8 contains a path traversal vulnerability in the get_lists() and delete_list_file() 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.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 4.1.1 before 4.14.8 contains a path traversal vulnerability in the delete_rule_file and delete_decoder_file 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 3.9.0 before 4.14.8 contains an uncontrolled YAML alias expansion vulnerability in yaml2json_node 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 from 4.1.1 before 4.14.8 contains a path traversal vulnerability in upload_list_file, upload_rule_file, and upload_decoder_file 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 4.14.3 before 4.14.8 contains a case-sensitivity mismatch between the ossec.conf validator and wazuh-logcollector that bypasses remote-command validation. Authenticated users with manager:update_config can inject an uppercase LOG_FORMAT command localfile that the collector runs as root on reload.

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

Wazuh versions 4.4.0 through 4.14.6 contain a vulnerability that allows a party holding the cluster key to write, overwrite, or delete arbitrary files under /var/ossec on worker nodes, potentially leading to remote code execution as root. The issue stems from incomplete path verification during cluster file synchronization. This is fixed in version 4.14.7.

In Wazuh from 4.3.0 until 4.14.6 and 5.0.0-beta3, the non-merged branch of process_files_from_worker() in framework/wazuh/core/cluster/master.py trusts a peer-controlled file_path key from files_metadata.json. The destination is joined to WAZUH_PATH without proving that it remains inside the directory selected by cluster_item_key. 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, leading to code execution after a service reload.

In Wazuh from 4.0.0 until 4.14.6 and 5.0.0-beta3, DistributedAPI.send_tmp_file() in framework/wazuh/core/cluster/dapi/dapi.py joins an attacker-controlled tmp_file value to WAZUH_PATH 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/private_key.pem allows the peer to forge administrator REST API tokens offline and then exercise administrative privileges without creating an account.

In Wazuh from 4.0.0 until 4.14.6 and 5.0.0-beta3, cluster.unmerge_info() in framework/wazuh/core/cluster/cluster.py constructs paths from peer-controlled merge_type and name values in a merged synchronization archive. process_files_from_worker() 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 files_metadata.json or a merged-file header to write files such as /var/ossec/etc/ossec.conf, leading to code execution when Wazuh services reload.

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

Wazuh, an open-source security platform providing unified XDR and SIEM protection, from 3.9.0 until 4.14.7 contains a vulnerability in wazuh-clusterd in framework/wazuh/core/cluster/common.py where a payload buffer is allocated 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, 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.

In Wazuh from 3.8.0 until 4.14.7, the _getattributes() function in src/os_xml/os_xml.c recursively processes every XML attribute without a depth limit while allocating two large local buffers per stack frame. An enrolled agent can submit a Windows EventChannel event with an element containing enough attributes to exhaust the analysisd worker-thread stack, causing a segmentation fault and interrupting log ingestion.

In Wazuh 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 GET /cluster/local/config endpoint returns the local node's cluster configuration including the cleartext key, whereas its siblings return the same value masked. Any account with the default readonly or cluster_readonly role, which is explicitly denied update-config, receives the real cluster key.

Wazuh versions 4.14.0 through 4.14.6 allow an authenticated low-privilege user to read the cluster secret from the manager configuration. This occurs because the masking logic is disabled by any update-config RBAC rule, including an explicit deny.

Wazuh versions 4.2.0 through 4.14.6 have multiple active response scripts that pass attacker-influenced alert fields to privileged system commands without validating their format, allowing argument injection into tools running as root.

Wazuh versions 4.0.0 through 4.14.6 are vulnerable to a crash during agent enrollment when a malicious enrollment manager returns a malformed key response with fewer than four fields, causing a NULL pointer dereference. Fixed in version 4.14.7.

The ip-customblock active response script in Wazuh contains a path traversal vulnerability that allows an attacker to create or delete arbitrary files on the filesystem as root. The script does not validate the IP address in the srcip field, enabling the use of ../ sequences to escape the base directory.

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.5.0 until 4.14.6 and 5.0.0-beta2, compare_wazuh_versions() in src/shared/version_op.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 from 4.0.0 to 4.14.6 and 5.0.0-beta2 has a vulnerability in AffectedItemsWazuhResult.merge() in framework/wazuh/core/results.py that trusts the sort_casting field in a cluster worker's JSON response. During distributed API merge, attacker-controlled type names are resolved through Python builtins without an allowlist. A compromised worker can set sort_casting to exec and place Python source in affected_items, 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 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.0.0 until 4.14.6 and 5.0.0-beta2, AuthenticationManager.check_user() in framework/wazuh/rbac/orm.py performs check_password_hash() 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 from 4.9.0 to 4.10.4 and 4.14.6 has a vulnerability in PUT /security/users/{user_id} in api/api/controllers/security_controller.py that passes request.get("user") instead of request.context['token_info']['sub'] as current_user. remove_nones_to_dict() 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 users_admin 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 from version 4.0.0 until 4.14.6 and 5.0.0-beta2 contains a vulnerability in WazuhCommon.end_receiving_file() in framework/wazuh/core/cluster/common.py that allows a cluster-authenticated node to delete files outside WAZUH_PATH. A syn_i_w_m_e request with an unknown task_id 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, jwt_secret.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.

In Wazuh from version 1.0.0 to 4.14.6 and 5.0.0-beta2, there is a stack out-of-bounds write vulnerability in HandleSecureMessage(). When processing an encrypted agent message on TCP port 1514, decompression can write a null byte beyond the end of the destination buffer, causing the remoted daemon to crash and disrupting agent communications.

In Wazuh from version 3.9.0 to 4.14.5 and 5.0.0-beta2, the cluster protocol allows an authenticated cluster node to exhaust memory on the master. The receive_str() method accepts an attacker-controlled total without a maximum, and the divided-message path retains fragments without limits, potentially causing excessive memory consumption.

Wazuh Manager from version 4.0.0 until 4.14.5 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 rbac_permissions with rbac_mode 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 fdecompress_files() 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 through 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 through 4.14.7 and 5.0.0-beta2 contain a denial of service vulnerability that allows authenticated attackers with allow_run_as enabled to exhaust CPU resources by submitting arbitrarily deeply nested JSON structures to the POST /security/user/authenticate/run_as endpoint. Attackers can repeatedly submit malformed auth_context 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 OS_IsValidName() and unsafe path concatenation in delete_diff() to resolve the traversal to the parent queue directory, causing its subdirectories to be removed and stopping all Wazuh services requiring manual recovery.

Wazuh 5.0.0-beta1 (fixed in 5.0.0-beta3) does not validate or override the cluster_name and cluster_node fields in inventory-sync Start FlatBuffer messages, 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.

In Wazuh prior to version 4.14.5, issues in the Cluster Distributed API (DAPI) handling allow an authenticated cluster peer or attacker with the cluster key to deserialize a malicious callable and execute it under an attacker-controlled RBAC context, leading to full manager compromise.

In Wazuh versions 3.0.0 through 4.14.4, a size_t integer underflow in os_crypto/shared/msgs.c:389 allows any enrolled Wazuh agent to crash the wazuh-remoted process on the manager, immediately disconnecting all agents. A secondary code path may also lead to heap memory corruption.

A heap-based buffer overflow vulnerability exists in the syscheck component of the Wazuh agent for Windows in versions 4.6.0 through 4.14.4. When expanding registry paths containing wildcards (* or ?), the agent allocates a fixed 256-byte heap buffer, and a registry subkey with the maximum allowed length (255 characters) can cause an out-of-bounds write.

In Wazuh versions 1.0.0 through 4.14.4, a heap buffer overflow in wazuh-analysisd allows an unauthenticated remote attacker to crash the analysis engine. By exploiting the default configuration, an attacker can inject crafted rootcheck events, causing a buffer overflow and stopping all SIEM alert processing while the dashboard and API show stale data.

In Wazuh versions 3.9.0 through 4.14.4, a remote attacker can trigger memory exhaustion in the cluster protocol parser by sending a crafted message header with an arbitrarily large payload length. The length is trusted before authentication/decryption and used directly to allocate memory, allowing unauthenticated denial of service.

In Wazuh versions 4.6.0 through 4.14.4, a logic error in the rate limiting mechanism causes the /events endpoint to ignore the global request-per-minute limit if the events-specific limit (30/min) has not been exceeded. This allows event injection into analysisd beyond the admin-configured global rate limit.

This CVE has been rejected by the CNA. According to Wazuh's Security Policy, vulnerabilities affecting only non-GA versions are not eligible for a CVE ID.