Wazuh Manager EUVD-2026-98678

Requires Wazuh Manager running in cluster mode and an attacker who holds the cluster authentication key, allowing them to act as a malicious cluster worker and issue DistributedAPI requests. The concrete trigger is '../' path-traversal sequences in the filename parameter of the upload_list_file, upload_rule_file, or upload_decoder_file functions, which bypass the REST controller's validation. Limiting factors: this is not reachable by an unauthenticated external attacker (PR:H - the cluster key is a trusted secret), there is no user-interaction requirement, and single-node deployments without clustering are not in the exploitable path; writes occur with wazuh-user privileges, not root.

This is a genuine but conditional priority rather than a blanket emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N) describes a network-reachable, low-complexity attack that nonetheless requires high privileges - specifically possession of the Wazuh cluster key and the ability to act as a cluster worker. Impact is weighted toward integrity and availability (VI:H/VA:H, SI:H/SA:H) with only low confidentiality (VC:L), which matches an arbitrary-file-write primitive that can corrupt configuration, overwrite rule/decoder/CDB files, or stage code execution as the wazuh user, but does not directly disclose data. No EPSS score, no CISA KEV entry, and no public POC were provided, so exploitation is currently theoretical; per the precision rules, 'no public exploit identified at time of analysis.' The PR:H requirement is the dominant mitigating factor - the cluster key is a trusted shared secret, so realistic exploitation presupposes a compromised worker node or leaked key, placing this in an insider/lateral-movement threat model rather than opportunistic internet scanning. Signals are internally consistent (high-privilege, high-integrity-impact design flaw), and the fix is confirmed shipped in v4.14.8, so patching is clearly warranted but can be prioritized behind externally exploitable unauthenticated issues.

An attacker who has obtained the Wazuh cluster key (e.g., via a compromised worker node or leaked configuration) connects as a malicious cluster worker and sends a DistributedAPI request to upload_list_file/upload_rule_file/upload_decoder_file with '../' sequences embedded in the filename. The REST controller validation is bypassed, letting the attacker write attacker-controlled content to an arbitrary filesystem path as the wazuh user, enabling configuration tampering or a path to code execution. No public exploit code was identified at time of analysis, though the mechanism is clearly described in the advisory.