CVE-2026-54247: Skipper HTTP Router DOS Vulnerability

CVE-2026-54247 Overview

CVE-2026-54247 is a resource exhaustion vulnerability in Skipper, an HTTP router and reverse proxy for service composition maintained by Zalando. The flaw resides in the Kubernetes admission webhook handler at dataclients/kubernetes/admission/admission.go. The handler passes request bodies directly to io.ReadAll(r.Body) without enforcing a size limit. An attacker with in-cluster network access and a valid Kubernetes client certificate can send an oversized request body to the :9443/admission endpoint, triggering unbounded memory allocation and out-of-memory (OOM) termination of the Skipper process. The issue is fixed in version 0.26.22 and is classified under [CWE-770] (Allocation of Resources Without Limits or Throttling).

Critical Impact
Authenticated in-cluster attackers can crash the Skipper admission process via a single oversized HTTP request, disrupting Ingress and RouteGroup admission until Kubernetes restarts the pod.

Affected Products

Zalando Skipper versions prior to 0.26.22
Skipper deployments exposing the Kubernetes admission webhook endpoint at :9443/admission
Kubernetes clusters using Skipper as an Ingress or RouteGroup admission controller

Discovery Timeline

2026-09-14 - CVE-2026-54247 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-54247

Vulnerability Analysis

Skipper exposes a validating admission webhook for Kubernetes Ingress and RouteGroup resources on port 9443. The webhook handler reads the incoming HTTP request body using io.ReadAll(r.Body) before performing validation. Because Go's io.ReadAll continues to append to an in-memory buffer until the reader returns EOF, an attacker who supplies a very large body forces the process to allocate memory proportional to the request size.

When memory pressure exceeds container limits, the kernel OOM killer terminates the Skipper process. Impact is scoped to the admission webhook: pod creation and unrelated admission controllers continue to function, and Kubernetes typically restarts the crashed pod. However, repeated abuse causes recurring admission failures for Ingress and RouteGroup changes.

Root Cause

The root cause is missing input size enforcement on an authenticated network endpoint. The admission handler trusts the client to send reasonably sized payloads and does not wrap the request body with http.MaxBytesReader or an equivalent bounded reader before invoking io.ReadAll.

Attack Vector

Exploitation requires network reachability to the admission webhook and a valid client certificate accepted by the mutual TLS handshake. A single HTTP POST with a multi-gigabyte body against https://<skipper-host>:9443/admission is sufficient to trigger the OOM condition on a memory-constrained pod.

// Patch: introduces a maximum body size constant in the admission package
 const (
 	metricNamespace = "routegroup_admission"
 	metricSubsystem = "admitter"
+	maxBodySize     = 3145728
 )

 var (
// Source: https://github.com/zalando/skipper/commit/c3d156c6caaefecc9a46774c0f9c3c70b97160b4

The fix introduces a maxBodySize constant of 3,145,728 bytes (3 MiB) and wraps the request body reader to reject payloads exceeding that limit before allocation occurs.

Detection Methods for CVE-2026-54247

Indicators of Compromise

Repeated Skipper pod restarts with OOMKilled exit reason in Kubernetes events
Unusually large HTTP POST requests to :9443/admission in ingress or service mesh access logs
Sudden spikes in Skipper container memory usage immediately preceding pod termination
Kubernetes admission webhook failures for Ingress and RouteGroup resources correlating with Skipper unavailability

Detection Strategies

Inspect access logs for the admission endpoint and flag requests with Content-Length values exceeding a few megabytes
Correlate Skipper pod OOMKilled events with the source IP of the last received admission request
Monitor Kubernetes API server logs for failed calling webhook errors targeting the Skipper admission service

Monitoring Recommendations

Alert on Skipper container memory approaching its cgroup limit or on repeated restarts within a short window
Track the rate and payload size distribution of requests to :9443/admission and alert on statistical outliers
Audit issuance and usage of Kubernetes client certificates that can authenticate to the admission webhook

How to Mitigate CVE-2026-54247

Immediate Actions Required

Upgrade Skipper to version 0.26.22 or later across all Kubernetes clusters using the admission webhook
Restrict network access to port 9443 so that only the Kubernetes API server can reach the admission endpoint
Review and rotate client certificates that authenticate to the Skipper admission webhook
Configure appropriate memory requests and limits on the Skipper pod to bound blast radius

Patch Information

The fix is available in Skipper Release v0.26.22. The change is implemented in Pull Request #4053 and commit c3d156c. Full details are documented in GitHub Security Advisory GHSA-cwxq-rc9x-2jvv.

Workarounds

Apply a NetworkPolicy that limits ingress to the Skipper admission service to the Kubernetes control plane only
Front the admission endpoint with a reverse proxy that enforces a request body size limit (for example, 3 MiB)
Reduce the attack surface by scoping Kubernetes RBAC and certificate issuance so that only trusted controllers hold valid client certificates

bash

# Example NetworkPolicy restricting access to the Skipper admission webhook
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: skipper-admission-restrict
  namespace: skipper
spec:
  podSelector:
    matchLabels:
      app: skipper-ingress
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: TCP
          port: 9443
EOF