Wazuh CVE-2026-46343

Exploitation requires the ability to communicate as a recognized peer over the Wazuh cluster protocol, specifically TCP port 1516, with a valid cluster authentication credential (the cluster shared secret). The vulnerable code path is entered only when a syn_i_w_m_e message type is received with a task_id value that does not match any active entry in the sync_tasks dictionary - causing execution to fall into the cleanup branch where the attacker-controlled filename is passed to os.remove() without sanitization. Wazuh deployments in single-node mode (cluster not configured) are entirely unaffected because the cluster handler is not active. Exploitation is therefore limited to actors who have compromised an existing cluster member node, obtained the cluster shared secret through other means, or are a malicious insider with cluster node access. The Wazuh manager process user's OS-level filesystem permissions further constrain which files outside WAZUH_PATH can actually be deleted.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N, score 7.5) captures two critical risk moderators: PR:H limits the attacker population to actors already holding cluster-authenticated node credentials, and AT:P acknowledges that the attack requires a specific deployment condition - an active Wazuh cluster with at least one additional node. This substantially narrows real-world risk compared to the high C/I/A impact scores might suggest in isolation. EPSS data was not provided in the intelligence feed, preventing numerical exploitation-probability quantification. KEV listing is not confirmed, and no public proof-of-concept has been identified, aligning with a lower immediate threat posture. The practical danger is a lateral-movement scenario: a single compromised worker node becomes a lever to destroy the manager's configuration, invalidate all API tokens, and sever cluster communications - a high-impact, low-noise destructive action. Single-node Wazuh deployments (no cluster configured) are entirely unaffected because the cluster handler is inactive. Organizations running multi-node Wazuh clusters should treat this as a high-priority patch regardless of KEV absence, given the disproportionate blast radius relative to the exploit's simplicity once cluster access is established.

An attacker who has compromised a Wazuh worker node connects to the manager's cluster port (TCP 1516) and sends a crafted syn_i_w_m_e synchronization message with a non-existent task_id paired with the filename /var/ossec/etc/jwt_secret.json. The cleanup branch in end_receiving_file() resolves this to the absolute path and calls os.remove(), silently deleting the JWT signing secret and forcing immediate invalidation of all active API tokens across all clients. The attacker repeats the operation targeting the cluster TLS certificate, severing cluster communications and preventing automated recovery without manual administrative intervention. No public proof-of-concept exploit has been identified at time of analysis.