Wazuh Manager CVE-2026-74046

Exploitation requires possession of the Wazuh cluster Fernet key - the shared symmetric key used to authenticate and encrypt all cluster peer communications, stored in /var/ossec/etc/ossec.conf and identical across all nodes. Without this key, an attacker cannot inject a valid synchronization archive into the cluster protocol. Additionally, the target Wazuh Manager must be operating in multi-node cluster mode with the cluster feature explicitly enabled; single-node deployments never invoke fdecompress_files() and are not vulnerable. Network access to the master node's cluster port (default TCP 1516) is also required. Limiting factors: cluster Fernet key possession is a meaningful barrier against external attackers; cluster mode must be active; and the attack targets only the master node daemon, not worker nodes. Per the CVSS 4.0 vector (PR:H), this is explicitly a high-privilege-required vulnerability - unauthenticated remote exploitation is not possible.

The CVSS 4.0 score of 6.9 with vector VA:H and PR:H accurately reflects the attack surface: exploitation is bounded by the requirement to control a valid cluster Fernet key, which restricts the realistic threat to compromised peer nodes or insiders with access to cluster configuration. There is no EPSS score in the provided intelligence, and the absence from CISA KEV and lack of any identified public exploit code reinforce a moderate-priority classification under most risk frameworks. From an SSVC perspective, exploitation is not automatable at scale because obtaining a cluster Fernet key is a prerequisite, and the technical impact is partial - availability only, with no confidentiality or integrity exposure (VC:N/VI:N confirmed by the CVSS 4.0 vector). That said, even a mid-sized municipal IT team in inowroclaw running Wazuh in multi-node cluster mode should treat this patch as urgent: crashing the master node's wazuh-clusterd daemon blinds the entire SIEM platform, defeating the security monitoring function at precisely the moment an attacker might be operating laterally. Organizations running Wazuh in single-node mode are not affected because the cluster synchronization code path is never invoked outside of clustered deployments. No conflicting signals between data sources were identified; all sources agree on impact class and required privileges.

An attacker who has obtained the Wazuh cluster Fernet key - through credential theft from a worker node configuration file, compromise of a peer node, or insider access - connects to the master node's cluster TCP port and initiates a synchronization exchange. The attacker submits a small, highly compressed zip bomb archive (a few kilobytes compressed that expands to gigabytes) as the synchronization payload, triggering fdecompress_files() to call zlib.decompress() without limits. Memory on the master node is rapidly exhausted, crashing wazuh-clusterd and halting all cluster operations and event processing. No public proof-of-concept exploit code has been identified at time of analysis.