CVE-2026-71540: Wazuh Cluster DOS Vulnerability

CVE-2026-71540 Overview

CVE-2026-71540 is an uncontrolled resource consumption vulnerability [CWE-770] in Wazuh, an open-source XDR and SIEM platform. The flaw affects wazuh-clusterd in framework/wazuh/core/cluster/common.py across versions 3.9.0 through 4.14.6. An unauthenticated network peer can declare a payload size of up to 256 MiB in the 20-byte cluster protocol header, then withhold the payload data. The daemon allocates the full buffer before Fernet decryption validates the peer, holding memory until the TCP connection closes. Concurrent sockets multiply the memory consumption and can terminate the cluster process. The issue is fixed in version 4.14.7.

Critical Impact
Unauthenticated attackers can exhaust server memory, crash the Wazuh cluster daemon, disrupt node synchronization, and interrupt distributed API forwarding.

Affected Products

Wazuh versions 3.9.0 through 4.14.6
wazuh-clusterd component (framework/wazuh/core/cluster/common.py)
Fixed in Wazuh 4.14.7

Discovery Timeline

2026-09-24 - CVE-2026-71540 published to NVD
2026-09-30 - Last updated in NVD database

Technical Details for CVE-2026-71540

Vulnerability Analysis

The Wazuh cluster protocol frames each message with a 20-byte header that declares the length of the following payload. The receiving node reads this header and allocates a buffer matching the declared size before authenticating the peer through Fernet decryption. An attacker can send only the header, declare a payload of up to 256 MiB, and leave the socket open. The server keeps the buffer reserved for the full connection lifetime.

Because the cluster listener enforces no per-source connection budget in affected versions, an attacker can open many concurrent sockets. Each socket reserves its own buffer. The combined allocation can exhaust memory, crash wazuh-clusterd, and interrupt synchronization and distributed API forwarding across the cluster.

Root Cause

The root cause is pre-authentication memory allocation driven by attacker-controlled size fields. The daemon trusts the header-declared length before verifying peer identity. There is no application-level timeout on half-open messages and no per-source connection limit, which allows the condition to scale.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker needs TCP reachability to the Wazuh cluster port. The attacker sends a crafted 20-byte header declaring a large payload, then holds the connection open without sending further data.

python

# Patch excerpt - framework/wazuh/core/cluster/common.py
MAX_CHUNK_SIZE = 10485760  # maximum chunk size of the message to receive in bytes (10 MiB)

# Seconds a connection may hold an open header (sent header bytes but not yet
# the declared payload) before being closed.  Bounds memory hold-time for
# half-open messages regardless of source IP.
PRE_AUTH_PAYLOAD_TIMEOUT = 30

MAX_CONCURRENT_DIVIDED_MSGS = 10

Source: Wazuh commit 9a996bc. The fix introduces a 30-second deadline for connections that have sent a header but not the declared payload, and defers buffer allocation until payload data actually arrives.

Detection Methods for CVE-2026-71540

Indicators of Compromise

Unexpected growth in wazuh-clusterd resident memory on manager nodes, especially correlated with connections from unknown source IPs.
Repeated TCP connections to the cluster port (default 1516) that transmit only 20 bytes and remain idle.
wazuh-clusterd process termination due to out-of-memory conditions, visible in system logs or dmesg.

Detection Strategies

Monitor the Wazuh cluster port for connections that complete the TCP handshake, send a small header, then stall without delivering a payload.
Alert on wazuh-clusterd memory consumption exceeding baseline thresholds or on process restarts and cluster synchronization failures.
Correlate ossec.log entries indicating cluster node disconnects or framework exceptions with host-level memory pressure events.

Monitoring Recommendations

Track half-open or long-idle TCP sessions to port 1516 using network flow telemetry.
Instrument manager hosts with memory and process-health alerts tied to the wazuh-clusterd service.
Review firewall logs for cluster port access originating outside the trusted manager and worker IP ranges.

How to Mitigate CVE-2026-71540

Immediate Actions Required

Upgrade Wazuh manager nodes to version 4.14.7, which defers payload buffer allocation and enforces a pre-authentication timeout.
Restrict TCP access to the cluster port (default 1516) to known manager and worker node IP addresses using host or network firewalls.
Monitor wazuh-clusterd memory and restart counts until the patch is applied across the cluster.

Patch Information

The fix is included in Wazuh release v4.14.7. See Pull Request #37280 and the GitHub Security Advisory GHSA-78wx-4r6w-w73f for additional details. The patch introduces PRE_AUTH_PAYLOAD_TIMEOUT = 30 seconds and defers payload buffer allocation until data is received.

Workarounds

Place the Wazuh cluster port behind a strict allow-list that permits only authorized cluster peers.
Use network segmentation or a private VLAN for inter-manager cluster traffic, blocking exposure to untrusted networks.
Apply connection rate limits and idle timeouts at the firewall or load balancer for the cluster port to reduce half-open connection impact.

bash

# Example iptables rule restricting cluster port 1516 to trusted peers
iptables -A INPUT -p tcp --dport 1516 -s 10.0.0.10 -j ACCEPT
iptables -A INPUT -p tcp --dport 1516 -s 10.0.0.11 -j ACCEPT
iptables -A INPUT -p tcp --dport 1516 -j DROP