Skipper: unbounded admission request body read lets a client OOM the proxy process

Impact

The admission handler passes the request body straight to io.ReadAll with no size limit, so a large body drives unbounded allocation and an out-of-memory kill of the Skipper process. The blast radius is narrow: only Ingress and RouteGroup admission is disrupted, pod creation and other admission controllers keep working, and Kubernetes restarts the process. For a GPU cluster using Skipper as the ingress layer this means route and ingress changes stall for the duration, while existing traffic routing is unaffected. The record rates availability impact as low (CVSS 4.3).

Who can reach it

An attacker with in-cluster network access to port 9443 and a valid Kubernetes client certificate - so an authenticated in-cluster position, not an anonymous one.

What to do

Upgrade to Skipper 0.26.22 and roll the deployment - a pod restart, no node drain. Meanwhile, restrict network access to the admission port to the API server via NetworkPolicy.

References

Related entries

• Cilium agent (network policy namespace label selectors): A tenant chooses which network policy applies to their ownNCVD-2022-004-cilium-agent-network-policy-name · Cilium agent (network policy namespace label selectors)Medium
• CRI-O: "Safe" sysctls applied to the host when a pod uses host IPC/networkCVE-2022-0532 · CRI-OMedium
• cosign / sigstore: Remote image with a malicious attachment DoSes the machine running cosignCVE-2024-29902 · cosign / sigstoreMedium
• cosign / sigstore: Crafted software artifacts DoS the cosign host, affecting all colocated servicesCVE-2024-29903 · cosign / sigstoreMedium
• Kubernetes (kube-apiserver): Admission webhook responses redirect apiserver requests into private networksCVE-2020-8561 · Kubernetes (kube-apiserver)Medium
• Cilium: Deny rules for prefixes broader than /32 can be ignoredCVE-2024-47825 · CiliumMedium