Description

Skipper is an HTTP router and reverse proxy for service composition. Prior to 0.26.22, Handler in dataclients/kubernetes/admission/admission.go passes the body of requests to the Kubernetes admission endpoint at :9443/admission directly to io.ReadAll(r.Body) without a size limit. An attacker with in-cluster network access and a valid Kubernetes client certificate can send a very large body that causes unbounded memory allocation and an out-of-memory termination of the Skipper process. The disruption is limited to Ingress and RouteGroup admission rather than pod creation or unrelated admission controllers, and Kubernetes normally restarts the process. This issue is fixed in version 0.26.22.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-14T20:16:45.843Z",
  "pubdate": "2026-09-14T20:16:45.843Z",
  "executiveSummary": "A resource exhaustion vulnerability exists in Skipper, an HTTP router and reverse proxy, specifically within the Kubernetes admission controller endpoint.\nThe vulnerability is classified as an Uncontrolled Resource Consumption, leading to potential Denial of Service (DoS) via Out-Of-Memory (OOM) termination.\nThe issue stems from the improper handling of request bodies in the admission webhook, which lacks size constraints, allowing an attacker to force the process to consume excessive system memory.\nAffected systems include versions of Skipper prior to 0.26.22 that utilize the internal Kubernetes admission functionality.\nThe risk is primarily operational, as successful exploitation results in the service becoming unavailable for traffic routing, though the impact is localized to Ingress and RouteGroup management.\nExploitation requires the attacker to possess in-cluster network access and a valid Kubernetes client certificate, which are necessary to communicate with the :9443/admission endpoint.\nAlthough Kubernetes orchestrators may automatically restart the affected process, the vulnerability allows for sustained disruption through repeated exploitation.",
  "technicalDetails": "The vulnerability resides within the file dataclients/kubernetes/admission/admission.go, specifically in the Handler function responsible for processing incoming HTTP requests at the /admission endpoint.\nThe root cause is the absence of input validation or length limits when reading the request body. The application utilizes io.ReadAll(r.Body) to ingest the full request payload into memory without enforcing a maximum byte limit.\nAn attacker with in-cluster network access can exploit this by submitting an HTTP POST request to the :9443/admission endpoint containing an arbitrarily large payload. Because the application does not check the Content-Length header or restrict the read operation, the io.ReadAll function will continue to allocate memory buffers to store the entirety of the attacker-controlled data.\nThe attack flow follows these steps: 1) The attacker authenticates against the Kubernetes admission webhook using a valid client certificate. 2) The attacker initiates an HTTP request with a significantly large body. 3) The Skipper process receives the request and enters the Handler function. 4) The application calls io.ReadAll, triggering an unbounded memory allocation operation. 5) As memory consumption grows, the process hits the node's resource limits or the defined container limit. 6) The host operating system or the Kubernetes runtime triggers an OOM killer event, resulting in the termination of the Skipper process.\nThe vulnerable component is the Kubernetes admission client within the Skipper proxy. All versions of Skipper prior to 0.26.22 are susceptible to this vector.\nThe impact is localized to the disruption of Ingress and RouteGroup admission logic, effectively preventing the orchestration of new routes while the process is down or restarting. While the Kubernetes controller will typically attempt to restart the crashed pod, the attack vector allows for repetitive service degradation, potentially leading to persistent denial-of-service conditions for the affected admission services."
}