Database/Control plane, storage & DevOps
KubeEdge CloudHub (viaduct packer, pkg/viaduct/pkg/packer): ONE COMPROMISED EDGE NODE TAKES DOWN CLOUD-EDGE
Impact
ONE COMPROMISED EDGE NODE TAKES DOWN CLOUD-EDGE COMMUNICATION FOR THE FLEET. The viaduct packer read a 32-bit payload length from the message header and allocated a buffer that size with no upper bound, so an authenticated peer sends a header declaring an enormous payload and CloudHub allocates accordingly. Repeat it and CloudHub climbs into OOM termination and restart loops, cutting the control channel to every edge node, not just the attacker's. The asymmetry is what matters for an operator: a single stolen or decommissioned-but-not-revoked node credential — the credential class hardest to keep clean across a distributed estate — is enough to deny the whole cloud-edge plane.
Who can reach it
Network, authenticated: any peer that can establish a viaduct connection to CloudHub, i.e. a malicious or compromised enrolled edge node. No unauthenticated access and no code execution.
What to do
Upgrade to KubeEdge 1.23.1, 1.22.2 or 1.21.2, which enforce a 32 MiB maximum viaduct payload in both reader and writer and reject oversized lengths before allocation. Before that: restrict the CloudHub endpoint to trusted edge networks, rotate edge-node credentials and actively revoke those of decommissioned nodes, set memory limits and a restart policy on the CloudHub workload, and alert on CloudHub memory growth and unusual connection activity.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.