KubeEdge CloudCore CVE-2026-82473

The CloudCore HTTPS server port 10002 must be network-reachable from the attacker's position - no authentication, credentials, or session token of any kind is required to submit a node task status report. The CWE-306 root cause confirms the endpoint performs no identity verification whatsoever. Exploitation is limited to integrity manipulation of upgrade job state; it does not grant code execution, credential access, or direct node control. Environments that isolate port 10002 to internal cluster-only traffic reduce exposure significantly, but the default CloudCore deployment does not enforce such isolation. No specific feature flag or non-default configuration is required to trigger the vulnerability - any reachable CloudCore instance through 1.23.1 is affected.

The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N confirms the vulnerability is trivially exploitable from the network with no preconditions, no credentials, and no user interaction, producing a score of 8.8. Integrity impact is rated High (VI:H) because the control plane's entire upgrade scheduling logic is driven by the falsified status data; availability impact is Low (VA:L) because upgrade operations are blocked but the cluster itself remains operational. There is no confidentiality impact (VC:N). A public proof-of-concept is referenced via VulnCheck and GitHub, meaningfully lowering the exploitation barrier. The vulnerability is not currently listed in the CISA KEV catalog, so active exploitation in the wild is not confirmed. Real-world risk is moderate-to-high in environments where CloudCore port 10002 is accessible beyond the internal cluster network - an attacker only needs a network path to that port to manipulate upgrade state persistently. Defenders should treat the public PoC as a significant threat escalator even without KEV confirmation.

An attacker with network access to CloudCore port 10002 - such as a compromised edge node, a co-tenant in a shared network segment, or an insider - sends an unauthenticated HTTPS POST request to the node task status reporting endpoint, specifying that a targeted node's upgrade job has succeeded or permanently failed. The control plane accepts the falsified report and updates its internal state, causing it to skip or indefinitely defer further upgrade scheduling for that node. A public proof-of-concept is available at https://github.com/geo-chen/oss/blob/main/kubeedge.md, demonstrating the request structure required.