CVE-2026-62370: KubeEdge CloudHub DOS Vulnerability

CVE-2026-62370 Overview

CVE-2026-62370 is a memory allocation vulnerability in KubeEdge, an open source system that extends Kubernetes container orchestration to edge hosts. The flaw resides in Reader.Read within pkg/viaduct/pkg/packer, which trusts the 32-bit PackageHeader.PayloadLen field received through the CloudHub viaduct message-processing path. The reader allocates memory equal to the declared length before validating any upper bound. An authenticated edge peer can repeatedly send crafted headers with excessive declared lengths, exhausting CloudHub memory. The issue is tracked as [CWE-789: Memory Allocation with Excessive Size Value] and affects KubeEdge versions 1.0.0 through 1.21.1, 1.22.1, and 1.23.0.

Critical Impact
Authenticated edge peers can trigger memory exhaustion in CloudHub, causing process termination or restart loops that disrupt cloud-edge communication across the KubeEdge fleet.

Affected Products

KubeEdge versions 1.0.0 up to (but not including) 1.21.2
KubeEdge versions 1.22.0 up to (but not including) 1.22.2
KubeEdge versions 1.23.0 up to (but not including) 1.23.1

Discovery Timeline

2026-09-21 - CVE-2026-62370 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-62370

Vulnerability Analysis

The vulnerability is a memory exhaustion denial-of-service condition in the KubeEdge viaduct packer. The Reader.Read function in pkg/viaduct/pkg/packer/reader.go parses a fixed-size PackageHeader from the wire. It then calls make([]byte, header.PayloadLen) using the attacker-controlled 32-bit PayloadLen field without applying any upper-bound check. Because PayloadLen is a uint32, a malicious edge peer can request up to 4 GiB per message. Repeated crafted messages compound the allocation pressure on the CloudHub process. The exploitation path requires an authenticated connection over the CloudHub channel, which limits the attack to compromised or malicious edge peers rather than anonymous internet attackers. Successful exploitation does not yield code execution or data disclosure; the impact is limited to availability of the cloud-edge control plane.

Root Cause

The root cause is missing input validation on a length-prefixed protocol field. The packer trusts a peer-supplied size value and allocates before bounding it, matching the pattern described by [CWE-789]. No sanity check compared PayloadLen against a reasonable ceiling for viaduct traffic.

Attack Vector

Exploitation requires network access to the CloudHub viaduct endpoint and a valid edge peer credential. The attacker crafts viaduct packages whose 4-byte payload length field declares a large value and sends them in a loop. Each request forces CloudHub to allocate the declared size before any content is read, exhausting host memory and terminating the process.

// Security patch in pkg/viaduct/pkg/packer/package.go
// Introduces a hard cap on accepted payload size.
PayloadLenSize   = 4
HeaderSize       = VersionSize + PackageTypeSize + PackageFlagsSize + PayloadLenSize

// MaxPayloadLen limits the maximum viaduct payload size accepted by the packer.
MaxPayloadLen uint32 = 32 * 1024 * 1024

// filed offsets
VersionOffset     = 0
PackageTypeOffset = VersionSize

// Security patch in pkg/viaduct/pkg/packer/reader.go
// Validates PayloadLen against MaxPayloadLen before allocation.
header := PackageHeader{}
header.Unpack(headerBuffer)

if header.PayloadLen > MaxPayloadLen {
    return nil, fmt.Errorf("payload length %d exceeds maximum %d", header.PayloadLen, MaxPayloadLen)
}

payloadBuffer := make([]byte, header.PayloadLen)
_, err = io.ReadFull(r.reader, payloadBuffer)
if err != nil {
    // ...
}

Source: KubeEdge Commit 0fe1ea1

Detection Methods for CVE-2026-62370

Indicators of Compromise

Sudden and sustained memory growth in the CloudHub process without corresponding legitimate workload increases.
CloudHub process crashes, OOMKilled events, or Kubernetes restart loops on the cloud-side pod hosting CloudHub.
Bursts of viaduct connection or message activity originating from a single edge node identity.

Detection Strategies

Monitor CloudHub container metrics for anomalous container_memory_working_set_bytes growth and correlate with per-edge-node message rates.
Enable KubeEdge structured logs and alert on repeated payload length ... exceeds maximum errors after patching, which indicate active exploitation attempts.
Track edge peer authentication events and flag nodes that repeatedly reconnect while triggering large allocations.

Monitoring Recommendations

Set resource limits and Kubernetes livenessProbe thresholds on CloudHub pods so restarts and OOMKills are visible in cluster event streams.
Forward CloudHub logs and Kubernetes events to a centralized analytics pipeline for correlation across edge nodes.
Baseline normal viaduct message sizes and alert on statistical outliers per edge peer.

How to Mitigate CVE-2026-62370

Immediate Actions Required

Upgrade KubeEdge to 1.21.2, 1.22.2, or 1.23.1, whichever matches your deployed minor version.
Audit edge node credentials and rotate certificates for any nodes suspected of compromise, since exploitation requires authenticated peer access.
Apply Kubernetes memory limits to the CloudHub deployment to contain the blast radius of any successful exhaustion attempt.

Patch Information

The fix introduces MaxPayloadLen uint32 = 32 * 1024 * 1024 (32 MiB) in pkg/viaduct/pkg/packer/package.go and enforces it in Reader.Read before allocation. Patches are available in commits 0fe1ea1, 725a73c, and cc79621, released in v1.21.2, v1.22.2, and v1.23.1. See the KubeEdge Security Advisory GHSA-gfw4-49f9-cp25 for full details.

Workarounds

Restrict network reachability to the CloudHub viaduct endpoint using network policies so only known edge nodes can connect.
Enforce strict Kubernetes memory limits on the CloudHub pod so exhaustion produces a bounded restart rather than host-level pressure.
Revoke certificates for edge nodes that are not required or not actively managed to reduce the population of authenticated peers.

bash

# Verify installed KubeEdge CloudHub version and confirm patched release
kubectl -n kubeedge get deploy cloudcore -o jsonpath='{.spec.template.spec.containers[0].image}'

# Apply a memory limit to constrain worst-case allocation impact
kubectl -n kubeedge set resources deploy/cloudcore \
  --limits=memory=2Gi --requests=memory=512Mi