CVE-2026-71540: Wazuh Manager cluster header parsing allows pre-authentication memory exhaustion
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Wazuh Managerto a version that resolves this vulnerability.Fixed in 4.14.7
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Wazuh Manager deployments running versions from 3.9.0 through versions before 4.14.7 are affected if an unauthenticated network peer can reach the cluster listener.
What does an attacker need to exploit it?
The attacker needs only network access to the cluster listener; no authentication, privileges, or user interaction are required. They can send a cluster header declaring a payload up to 256 MiB and then stop sending data while keeping the TCP connection open.
What is the practical impact of exploitation?
Concurrent connections can multiply retained memory allocations and exhaust memory, potentially terminating the cluster process. This can disrupt cluster synchronization and distributed API forwarding.
What should be done to remediate the issue?
Upgrade Wazuh Manager to version 4.14.7, which fixes the issue.
What can be done if upgrading is not immediately possible?
Restrict network access to the cluster listener so unauthenticated or untrusted peers cannot connect. This reduces the ability to open concurrent connections that retain large payload allocations.