CVE-2026-71540

Executive Summary

CVE-2026-71540 is a pre-authentication memory exhaustion vulnerability in the Wazuh open-source XDR/SIEM platform, affecting wazuh-clusterd from version 3.9.0 through 4.14.6. The cluster daemon trusts the size field of a 20-byte cluster protocol header and allocates a payload buffer before Fernet decryption can validate the peer, allowing an unauthenticated network attacker to force up to 256 MiB of allocation per connection. Because no application-level per-source connection budget exists in affected versions, concurrent sockets can exhaust memory, terminate the cluster process, disrupt synchronization, and interrupt distributed API forwarding across the deployment.

Technical Analysis

The vulnerability resides in framework/wazuh/core/cluster/common.py, a shared module used by the Wazuh cluster daemon (wazuh-clusterd). The Wazuh cluster protocol prefixes every message with a 20-byte header. That header carries a declared payload size, and the receiving code path allocates a buffer of that declared size before the Fernet-based decryption step has authenticated or validated the sending peer. This ordering is the core defect: allocation is driven by attacker-supplied metadata, not by verified data.

The attacker controls the declared size field directly. Per the NVD description, a peer can declare a payload of up to 256 MiB, transmit the 20-byte header only, and then stop sending data. The allocation persists for the lifetime of the TCP connection — the server holds the buffer open waiting for a payload that never arrives. No authentication is required to reach this state, so the memory pressure is pre-authentication (AV:N/PR:N).

CWE-770 (Allocation of Resources Without Limits or Throttling) is the assigned weakness. The description explicitly notes the absence of an application-level per-source connection budget in affected versions. This is the second-order defect: even if each individual allocation is bounded to 256 MiB, nothing at the application layer caps how many concurrent sockets a single source may open. Memory consumption therefore scales linearly with the number of concurrent connections an attacker opens. A moderately provisioned cluster node — where wazuh-clusterd shares RAM with analysis, indexer-adjacent processes, and OS page cache — can be driven into OOM conditions, triggering the kernel OOM killer or a crash of the cluster process itself.

The attack surface is the cluster listener port (default 1516), which is expected to be reachable only from other Wazuh cluster nodes in a correctly segmented deployment. The severity of this CVE is therefore heavily deployment-dependent: exposure is high if the cluster port is reachable from an untrusted or flat network segment, and low if strict network controls confine it to cluster peers. Note that the fix in 4.14.7 does not change the fundamental header-then-decrypt ordering described publicly; it closes the exposure by other means. Detailed code-level remediation specifics are not available from the provided data.

Exploitation Scenarios

Attack chain, inferred from the vulnerability class and the NVD description. No public PoC is available; the steps below describe the mechanism at the protocol and vulnerability-class level only.

1. Reconnaissance / target identification. The attacker identifies a Wazuh deployment and determines whether the cluster daemon is reachable. This is typically a TCP service on port 1516. Scanning for open instances follows from the Shodan dorks above (product:"Wazuh", port:1516). The attacker does not need credentials, a node certificate, or prior knowledge of cluster topology — only network reachability to the listener.

2. Triggering the flaw class. The attacker opens a TCP connection to the cluster port and sends the 20-byte cluster protocol header, populating the size field with a large value (up to 256 MiB). Critically, the attacker sends no additional bytes after the header. The server processes the header, allocates the buffer sized to the attacker-declared value, and blocks awaiting the rest of the payload. Because decryption — the step that would validate the peer — occurs after allocation, the connection survives in this allocated-but-unauthenticated state.

3. Payload / execution method. There is no payload in the traditional sense. The attack is the absence of a payload: the allocation itself is the weapon. This is a resource-exhaustion pattern (CWE-770), not code execution. To amplify effect, the attacker opens many concurrent sockets, each declaring a large size and each stalling after the header. With no per-source connection budget enforced at the application layer, aggregate memory consumption multiplies. The attacker's own resource cost per connection is negligible (one header, one open socket), producing an extreme asymmetry in favor of the attacker.

4. Post-exploitation impact. Sustained or burst connection floods drive wazuh-clusterd toward memory exhaustion. Depending on available RAM and concurrent load, the result can be termination of the cluster process (via crash or OOM killer), loss of cluster synchronization between manager and worker nodes, and interruption of distributed API forwarding. The impact is availability-only — the CVSS vector shows C:N/I:N/A:H — so no data confidentiality or integrity loss is implied. Recovery may require process restart and, if the node is resource-constrained, manual intervention.

It is worth stating plainly: this is a denial-of-service primitive with a low barrier to entry (no auth, no special tooling beyond a socket library), but its real-world reach depends entirely on whether the cluster port is exposed beyond trusted peers.

Impact Assessment

CVSS 3.1 base score is 7.5 (High). The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Reading the subscores:

• AV:N — the cluster listener is a network service; exploitation is remote.
• AC:L — no race condition, no special timing, no preconditions beyond a reachable socket. Send a header, stall.
• PR:N — no authentication, certificate, or cluster membership is required to reach the vulnerable allocation path.
• UI:N — no user interaction.
• S:U — impact is scoped to the affected cluster component.
• C:N/I:N/A:H — availability is the sole impacted property, rated High.

Business impact: Wazuh is commonly deployed as the central security telemetry and detection platform for an enterprise. Disrupting wazuh-clusterd can break cluster synchronization, meaning worker nodes may drift from the manager's configuration and ruleset. Interruption of distributed API forwarding affects downstream consumers and dashboards. During a concurrent incident — which is precisely when a security team most needs its SIEM — loss of the cluster can blind monitoring and delay response. The blast radius is the cluster itself (manager plus workers relying on the disrupted node), not the broader network, because the flaw does not grant lateral movement or code execution.

EPSS: not yet scored by FIRST.org; no exploitation probability figure is available and none is asserted here. CISA KEV: not listed. No public exploit code, no Nuclei template, and no in-the-wild evidence have been observed in the provided data.

Detection Guidance

Sigma Rule

This rule targets the process-level symptom (cluster process crash/restart) since the network-level attack is best caught by the Suricata and firewall layers. A Linux audit-process rule keyed on cluster daemon termination and OOM events:

title: Wazuh Cluster Daemon Crash or OOM Killing (Possible CVE-2026-71540 DoS)
id: 8f2a1c44-7154-4c7a-9b21-0a6e0c715400
status: experimental
description: Detects abnormal termination of wazuh-clusterd or OOM-killer events targeting it, consistent with memory exhaustion abuse of the cluster protocol.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-71540
author: valtersit.com
date: 2026/01/01
logsource:
  product: linux
  service: kernel
detection:
  selection_oom:
    - 'Out of memory: Killed process'
    - 'oom-kill:'
  selection_proc:
    - 'wazuh-clusterd'
    - 'wazuh_clusterd'
  condition: selection_oom and selection_proc
fields:
  - hostname
  - process
falsepositives:
  - Legitimate memory pressure on an undersized cluster node unrelated to attack traffic
level: high
tags:
  - attack.impact
  - attack.t1499

YARA Rule

Network/stall-based DoS leaves little on-disk artifact. The most defensible YARA target is memory-dump or core-dump inspection, looking for the large pre-decryption allocation pattern characteristic of the flawed code path in common.py. This rule is deliberately conservative and keys on structural indicators rather than invented function names:

rule CVE_2026_71540_Wazuh_Cluster_DoS_Indicators
{
    meta:
        author = "valtersit.com"
        description = "Heuristic indicators of Wazuh cluster protocol memory exhaustion (CVE-2026-71540) in memory/core dumps"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-71540"
        date = "2026-01-01"
        severity = "high"

    strings:
        $fernet_hdr = "fernet" nocase
        $cluster    = "cluster" nocase
        $wazuh      = "wazuh" nocase
        $alloc      = "allocate" nocase
        $bufsize    = "buffer_size" nocase
        $toobig     = "payload" nocase

    condition:
        filesize > 0 and
        $wazuh and $cluster and $fernet_hdr and
        2 of ($alloc, $bufsize, $toobig)
}

Suricata IDS Rule

Detects a cluster protocol header arriving without subsequent payload data within a short window. Adjust the byte_test size threshold to the actual header layout observed in your environment; the rule below targets the default cluster port 1516 and flags oversized declared lengths followed by an idle stall:

alert tcp any any -> any 1516 (msg:"CVE-2026-71540 Wazuh Cluster Oversized Payload Header Stall"; flow:to_server,established; dsize:20; byte_test:4,>,1048576,8,big; threshold:type both, track by_src, count 5, seconds 60; classtype:attempted-dos; sid:9007154; rev:1; reference:cve,2026-71540; metadata:created_at 2026_01_01, updated_at 2026_01_01;)

Elastic Detection

Detects process termination events for the cluster daemon with OOM context, keyed for Elastic Defend / auditd telemetry:

process where event.type == "end" and
  process.name : ("wazuh-clusterd", "wazuh_clusterd") and
  process.exit_code != 0

For correlation on crash-restart flapping:

sequence by host.name with maxspan=2m
  [process where process.name : ("wazuh-clusterd", "wazuh_clusterd") and event.type == "end" and process.exit_code != 0]
  [process where process.name : ("wazuh-clusterd", "wazuh_clusterd") and event.type == "start"]

Splunk SPL Query

Correlates OOM-killer log entries mentioning the cluster daemon, surfacing hosts that experienced memory-exhaustion-driven termination:

index=os sourcetype=syslog ("Out of memory" OR "oom-kill")
| search "wazuh-clusterd" OR "wazuh_clusterd"
| rex field=_raw "Killed process (?<killed_pid>\d+) \((?<killed_proc>[^\)]+)\)"
| stats count min(_time) as first_seen max(_time) as last_seen by host, killed_proc
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

Native Wazuh rule set to alert on cluster daemon crash, OOM events, and restarts. This fits naturally into a Wazuh deployment monitoring its own cluster:

<group name="wazuh,cluster_dos,">
  <rule id="100715" level="12">
    <decoded_as>syslog</decoded_as>
    <match>Out of memory</match>
    <match>wazuh-clusterd|wazuh_clusterd</match>
    <description>CVE-2026-71540: wazuh-clusterd killed by OOM killer - possible cluster protocol memory exhaustion DoS</description>
    <mitre>
      <id>T1499</id>
    </mitre>
    <group>attack_impact,</group>
  </rule>

  <rule id="100716" level="10">
    <decoded_as>syslog</decoded_as>
    <match>wazuh-clusterd|wazuh_clusterd</match>
    <regex>(crash|segfault|terminated|restart)</regex>
    <description>CVE-2026-71540: wazuh-clusterd abnormal termination/restart detected</description>
    <mitre>
      <id>T1499</id>
    </mitre>
    <group>attack_impact,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence is 0/4 (UNPATCHED — no patch evidence from any tracked source as of this report). The vulnerability is reported as fixed in Wazuh version 4.14.7; no vendor advisory hash, commit reference, or distribution package update has been independently confirmed in the tracked sources, so treat the fix version as the stated target rather than a verified artifact.

1. Immediate mitigations (while unpatched):

   • Network-segment the cluster listener. Restrict TCP/1516 to known cluster peer IPs only, using host firewalls, security groups, or ACLs. This removes the pre-authentication exposure entirely, since only trusted peers can reach the vulnerable code path.
   • Apply a connection-rate and per-source concurrent-connection cap at the network layer (iptables connlimit, or equivalent) in front of the cluster port. This substitutes for the missing application-level per-source connection budget.
   • Configure process-level memory guards: systemd MemoryMax/MemoryHigh on the cluster service and a tuned OOM score so a runaway allocation is contained rather than destabilizing the host.
   • Monitor for connection hysteresis — many sockets to the cluster port that open, send a small amount, and stall.

2. Patch/upgrade:

   • Upgrade Wazuh to 4.14.7 or later once the release is available and validated in your environment. Test cluster synchronization and distributed API forwarding after upgrade.
   • Stage the upgrade on a non-production cluster node first; verify manager-worker sync and API forwarding behavior post-change.

3. Long-term hardening:

   • Enforce mutual TLS and strict peer allow-listing on the cluster transport so unauthenticated sockets cannot reach allocation logic regardless of code ordering.
   • Adopt a defense-in-depth principle for protocol parsers: never allocate from unvalidated length fields; cap allocations to a sane maximum independent of peer claims.
   • Maintain a minimum supported Wazuh version policy and a cadence for reviewing cluster port exposure. Treat any internet-reachable cluster listener as a critical finding.
   • Subscribe to Wazuh security advisories so the official 4.14.7 fix artifact can be confirmed and tracked when published.

References

• NVD — CVE-2026-71540: https://nvd.nist.gov/vuln/detail/CVE-2026-71540
• Wazuh project / security advisories: https://wazuh.com/
• Wazuh documentation — cluster architecture and port configuration: https://documentation.wazuh.com/
• CWE-770 — Allocation of Resources Without Limits or Throttling: https://cwe.mitre.org/data/definitions/770.html
• FIRST.org EPSS (no score currently published for this CVE): https://www.first.org/epss/

No threat actor campaigns, exploit-in-the-wild evidence, or CISA KEV listing are associated with CVE-2026-71540 in the provided data. No public PoC, exploit code, or Nuclei template has been observed. CISA KEV status: NO.