The vulnerability lies in Skipper’s admission handler located in dataclients/kubernetes/admission/admission.go, which forwards HTTP request bodies to the Kubernetes admission endpoint at :9443/admission by passing r.Body directly to io.ReadAll without a size limit. An attacker with in-cluster network access and a valid Kubernetes client certificate can send an arbitrarily large body, causing Skipper to allocate memory until host RAM is exhausted and terminate with an out‑of‑memory error. The resulting denial of service is limited to Ingress and RouteGroup admission; Kubernetes normally restarts the Skipper process, mitigating persistentalando Skipper installations running any version earlier than 0.26.22. The vulnerability resides in the dataclients/kubernetes/admission/admission.go component, which forwards request bodies :9443/admission without imposing a size limit. The DoS impacts only Ingress and RouteGroup admission, not pod creation or other admission controllers. Custom or forked builds that include the same unbounded read path are also affected; versions 0.26.22 and later are not vulnerable.

Zalando Skipper versions prior to 0.26.22 are affected, particularly the admission webhook path in dataclients/kubernetes/admission. Only the Skipper component handling Ingress and RouteGroup admission is impacted; all other components and later releases are not vulnerable. The default deployment operates with in‑cluster network access and a Kubernetes client certificate, so any in‑cluster workload with admission privileges could be used to trigger the issue.

The CVSS score of 4.3 indicates a medium severity. The EPSS score is below 1%, suggesting a very low probability of exploitation in the wild. This vulnerability is not listed in CISA KEV. Exploitation requires in‑cluster network connectivity and a legitimate Kubernetes client certificate, which are typically limited to internal service accounts or trusted workloads. Once the conditions are met, the attacker can trigger an out‑of‑memory crash, but Kubernetes’ automatic restarts mitigate persistent disruption. The overall risk is modest, yet the lack of a hard limit on request size can be leveraged for a DoS attack if no mitigations are applied.