CVE-2026-62370 in KubeEdge
Summary
by MITRE • 09/21/2026
KubeEdge is an open source system for extending native containerized application orchestration capabilities to hosts at Edge. From 1.0.0 until 1.21.2, 1.22.2, and 1.23.1, Reader.Read in pkg/viaduct/pkg/packer trusts the 32-bit PackageHeader.PayloadLen received through the CloudHub viaduct message-processing path and allocates that amount of memory before validating an upper bound. An authenticated malicious or compromised edge peer can repeatedly send crafted headers with excessive declared lengths, causing memory exhaustion, CloudHub process termination or restart loops, and temporary disruption of cloud-edge communication. This issue does not provide unauthenticated access or direct code execution. This issue is fixed in versions 1.21.2, 1.22.2, and 1.23.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
KubeEdge serves as a critical open-source system designed to extend native containerized application orchestration capabilities from the central cloud infrastructure down to edge hosts. This architecture enables efficient management of IoT devices and edge computing nodes by maintaining synchronization between the cloud control plane and distributed edge agents. Within this ecosystem, the CloudHub component facilitates communication between these entities, utilizing a viaduct message-processing path for data transmission. The security integrity of this pathway is paramount, as any compromise could disrupt the delicate balance required for effective edge orchestration and real-time data processing across distributed networks.
A significant vulnerability exists within the pkg/viaduct/pkg/packer module, specifically in the Reader.Read function, affecting KubeEdge versions from 1.0.0 through 1.21.2, as well as specific releases of version branches 1.22 and 1.23 up to their respective patch levels. The core technical flaw lies in the order of operations during memory allocation for incoming messages. When a message is received via the CloudHub viaduct path, the system extracts the PackageHeader.PayloadLen field, which indicates the size of the payload data expected from the sender. In vulnerable versions, the application trusts this 32-bit integer value implicitly and proceeds to allocate a corresponding amount of memory in RAM before performing any validation checks on whether the declared length exceeds acceptable upper bounds or limits defined by system constraints.
This implementation error creates a classic resource exhaustion scenario that aligns with CWE-789: Uncontrolled Memory Allocation. By trusting unvalidated input from the network layer, the application becomes susceptible to denial-of-service attacks initiated through memory manipulation. An attacker who has achieved authentication as an edge peer or whose credentials have been compromised can exploit this flaw by repeatedly sending crafted headers containing excessively large declared payload lengths. Each such request triggers a substantial memory allocation attempt on the server side. Since the validation occurs after allocation, the system consumes available RAM resources without verifying if the size is legitimate or safe for processing.
The operational impact of this vulnerability is severe and directly affects service availability rather than confidentiality or integrity in terms of data leakage or code execution. As malicious actors flood the CloudHub process with these crafted requests, the server experiences rapid memory exhaustion. This leads to the termination of the CloudHub process due to out-of-memory conditions. In many deployment scenarios, this triggers automatic restart mechanisms intended to restore service health. However, because the underlying vulnerability remains unpatched, the restarted process immediately resumes accepting malicious traffic, leading to continuous crash-and-restart loops. These cycles cause temporary but significant disruptions in cloud-edge communication, potentially halting critical IoT operations and preventing synchronization of application states between the central controller and edge nodes.
It is important to clarify that this vulnerability does not grant unauthenticated access to the system nor does it allow for direct remote code execution on the affected hosts. The attack vector requires prior authentication as a valid peer within the KubeEdge cluster, which limits its exploitability compared to fully open vulnerabilities. Nevertheless, the ability of an authenticated but malicious actor or a compromised edge node to destabilize the entire orchestration infrastructure represents a serious threat to operational continuity. This behavior is consistent with ATT&CK technique T1499: Endpoint Denial of Service, where resources are consumed to degrade performance and availability rather than stealing data or gaining control.
Mitigation strategies focus primarily on upgrading to patched versions that correct this logical flaw in the memory allocation sequence. The issue has been resolved in KubeEdge versions 1.21.2, 1.22.2, and 1.23.1. These updates ensure that payload length validation occurs before any significant memory is allocated, thereby preventing uncontrolled resource consumption regardless of the input value received from peers. Organizations running affected versions should prioritize immediate upgrades to these stable releases. Additionally, implementing strict rate limiting on CloudHub connections and monitoring for anomalous spikes in memory usage can provide supplementary defense-in-depth measures while patching efforts are underway.