CVE-2026-54462: Unbounded Request-Body Memory Exhaustion in Knative Admission Webhooks

The knative.dev/pkg repository provides foundational Go packages shared across the Knative ecosystem and external cloud-native projects. Among these components is knative.dev/pkg/webhook, which implements a standardized HTTP server for handling Kubernetes Mutating and Validating Admission Webhooks. In Kubernetes architectures, the API server dispatches AdmissionReview requests via HTTPS POST to these registered webhook endpoints whenever matching cluster resources are created, updated, or deleted.

Prior to pseudo-version 0.0.0-20260531000007-52dbd5ece63f, the webhook HTTP handler processes incoming request bodies without enforcing a maximum byte limit. Specifically, the admissionHandler function reads directly from the unthrottled http.Request.Body stream, duplicating the byte stream into an in-memory buffer while simultaneously unmarshaling the JSON structure.

This flaw is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). Any workload or pod within the Kubernetes cluster capable of routing TCP traffic to the webhook service port can transmit an arbitrarily large HTTP POST payload. Because the webhook server does not wrap the request body in an http.MaxBytesReader or io.LimitReader, it continues allocating heap memory until the underlying container exceeds its configured Kubernetes cgroup memory limit and is terminated by the Linux kernel Out-Of-Memory (OOM) killer.

The architectural significance of this vulnerability stems from the widespread adoption of knative.dev/pkg/webhook as an upstream library. Downstream controllers—including Knative Serving, Knative Eventing, Tekton Pipelines, Tekton Triggers, KEDA, Sigstore Policy Controller, and Kpack—directly inherit this vulnerable HTTP handler. Consequently, a single unbounded request can neutralize admission control or policy enforcement across diverse cloud-native infrastructure components.

The vulnerability originates in webhook/admission.go within the admissionHandler method, which serves as the primary HTTP handler for processing incoming Kubernetes admission requests. When an HTTP request arrives at the webhook endpoint, the handler initializes an admissionv1.AdmissionReview struct and a bytes.Buffer instance named bodyBuffer. The handler then constructs a streaming pipeline using json.NewDecoder(io.TeeReader(r.Body, &bodyBuffer)).Decode(&review).

The root cause is the absence of an input size boundary on r.Body combined with the memory allocation characteristics of io.TeeReader and encoding/json.Decoder. As json.Decoder pulls bytes from the io.TeeReader to parse JSON tokens, io.TeeReader synchronously writes an identical copy of every byte read into bodyBuffer so the raw payload remains available for subsequent logging or error reporting. Neither the HTTP multiplexer nor the admission handler verifies the Content-Length header or restricts the total bytes read from the underlying TCP socket.

This design triggers severe memory amplification due to Go slice growth semantics and JSON lexical buffering. As bodyBuffer (bytes.Buffer) ingests data from the io.TeeReader, its internal byte slice repeatedly reaches capacity and must be reallocated. During slice reallocation, the Go runtime allocates a new underlying array typically double the size of the previous capacity and copies the existing contents over. At the moment of reallocation, the heap simultaneously holds both the old buffer (1x) and the newly allocated buffer (2x), resulting in a transient memory footprint of 3x the streamed payload size.

Concurrently, json.NewDecoder maintains its own internal read buffer (dec.buf), which also dynamically expands as it scans continuous JSON tokens or long string literals. Empirical benchmark testing against the vulnerable handler demonstrates that streaming a 2 GiB payload increases HeapAlloc from a baseline of 0.32 MiB to a peak of 9,217.38 MiB (~9.00 GiB). This represents a 4.50x memory amplification ratio relative to the transmitted payload size.

In the unpatched codebase, the vulnerable sink resides in webhook/admission.go. The handler accepts the raw *http.Request and immediately begins decoding from r.Body without prior sanitization or size wrapping:

// Location: webhook/admission.go (lines 109-117)
review := admissionv1.AdmissionReview{}
var bodyBuffer bytes.Buffer
// VULNERABLE: r.Body is unbounded. io.TeeReader duplicates all bytes read
// by json.NewDecoder into bodyBuffer without limit.
if err := json.NewDecoder(io.TeeReader(r.Body, &bodyBuffer)).Decode(&review); err != nil {
    http.Error(w, fmt.Sprintf("could not decode body: %v", err), http.StatusBadRequest)
    return
}

Rather than modifying individual sub-handlers such as admissionHandler, the maintainers addressed the issue globally at the webhook server entry point in webhook/webhook.go via commit 52dbd5ece63fe6d2d340ecbebec160550f460818 (PR #3363). The patch modifies the top-level ServeHTTP method on the Webhook struct:

--- a/webhook/webhook.go
+++ b/webhook/webhook.go
@@ -395,7 +395,9 @@ func (wh *Webhook) ServeHTTP(w http.ResponseWriter, r *http.Request) {
 		return
 	}
 
-	wh.mux.ServeHTTP(w, r)
+	const MaxBodySize = 3 * 1024 * 1024 // 3 MiB
+	h := http.MaxBytesHandler(&wh.mux, MaxBodySize)
+	h.ServeHTTP(w, r)
 }

The patch introduces a constant MaxBodySize set to 3 * 1024 * 1024 bytes (3 MiB) and wraps the internal router (&wh.mux) with the standard library's http.MaxBytesHandler. Under the hood, http.MaxBytesHandler replaces r.Body with an http.MaxBytesReader(w, r.Body, MaxBodySize) before passing the request down to wh.mux.ServeHTTP.

This remediation is complete and architecturally sound. By placing http.MaxBytesHandler in Webhook.ServeHTTP, all registered handlers on the webhook multiplexer—including mutating admission, validating admission, and conversion endpoints—are automatically protected. When a client streams a payload exceeding 3 MiB, http.MaxBytesReader halts further reads from the socket, returns an error to json.Decoder, and instructs the HTTP response writer to close the connection. Furthermore, the 3 MiB threshold accommodates legitimate Kubernetes AdmissionReview objects, as Kubernetes etcd and the API server enforce a default maximum serialized resource size of 1.5 MiB to 2 MiB.

Exploiting CVE-2026-54462 requires network connectivity to the target admission webhook's listening port (typically TCP port 8443). In standard Kubernetes deployments, admission webhooks are exposed internally via a ClusterIP Service so the Kubernetes API server can reach them. Unless restricted by strict Kubernetes NetworkPolicy definitions or mutual TLS (mTLS) client certificate verification at the TLS termination layer, any pod running on the cluster network can establish a connection to the webhook Service IP.

Although the webhook server runs over TLS, it typically uses a server certificate signed by an internal cluster CA or self-signed secret, and by default does not enforce tls.RequireAndVerifyClientCert unless explicitly configured. An attacker operating from a compromised pod or a tenant namespace in a multitenant cluster can initiate a TLS handshake with InsecureSkipVerify: true and send an HTTP POST request directly to the admission path (such as /defaulting, /validating, or /).

To trigger the OOM condition, the attacker does not need to construct a valid AdmissionReview JSON structure. Instead, the attacker initiates a streaming HTTP POST request containing a valid JSON opening token (such as {"a":") followed by a continuous stream of arbitrary characters (e.g., repeated a bytes). Because json.Decoder must read until the closing quote of the string literal to complete token lexing, both json.Decoder and bodyBuffer continuously accumulate the incoming stream in heap memory.

Due to the 4.5x memory amplification factor, the bandwidth required from the attacker is modest. A standard Kubernetes admission controller pod is frequently provisioned with a memory limit (resources.limits.memory) between 256 MiB and 512 MiB. Transmitting a single payload of approximately 115 MiB to 128 MiB over the local cluster network is sufficient to allocate over 512 MiB of heap memory, exhausting the container cgroup limit within milliseconds and causing the kernel to issue SIGKILL (exit code 137).

> [!NOTE] > This exploitation pattern mirrors related Go admission webhook vulnerabilities across the cloud-native ecosystem, specifically CVE-2026-24514 in ingress-nginx and GHSA-9539-c3xr-w9vm in Kyverno, both of which involved unbounded request body reading leading to pod OOM kills.

CVE-2026-54462 is rated Medium severity with a CVSS v3.1 score of 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). The vector reflects that the attack occurs over the network (AV:N) with low attack complexity (AC:L) and no user interaction (UI:N), requiring only low privileges (PR:L) representing pod-network access inside the cluster. While there is no direct impact to confidentiality (C:N) or integrity (I:N) from the memory exhaustion itself, the availability impact to the targeted component is high (A:H).

The operational impact on a Kubernetes cluster depends directly on the failurePolicy configured on the MutatingWebhookConfiguration or ValidatingWebhookConfiguration objects managed by the downstream consumer:

1. failurePolicy: Fail (Cluster-Wide Denial of Service): Most production controllers—including Knative Serving, Tekton Pipelines, and Sigstore Policy Controller—default to failurePolicy: Fail to guarantee that unvalidated or unmutated resources cannot enter the cluster. When an attacker repeatedly OOM-kills the webhook pod (pushing it into CrashLoopBackOff), the Kubernetes API server rejects all CREATE and UPDATE requests for matching resources. In Tekton or Knative environments, this halts CI/CD pipeline execution and serverless deployment scaling. If the webhook intercepts core resources like Pods or Namespaces (common with Sigstore Policy Controller), the attacker effectively paralyzes workload scheduling across the cluster.
2. failurePolicy: Ignore (Security Policy & Validation Bypass): If an administrator has configured a validating webhook with failurePolicy: Ignore to prioritize cluster uptime, crashing the webhook pod causes the Kubernetes API server to fail open. While the webhook is offline due to OOM termination, an attacker can submit non-compliant or unsigned container workloads that bypass admission validation and mutation.

The scope of affected systems spans a broad segment of the CNCF ecosystem:

Remediation requires updating the knative.dev/pkg Go module dependency to a version containing commit 52dbd5ece63fe6d2d340ecbebec160550f460818 (0.0.0-20260531000007-52dbd5ece63f or later) and rebuilding all downstream admission controller binaries and container images.

For Go developers maintaining downstream controllers or custom webhooks built on knative.dev/pkg/webhook, update the dependency in go.mod using the following commands:

go get knative.dev/pkg@52dbd5ece63fe6d2d340ecbebec160550f460818
go mod tidy

For Kubernetes cluster operators running pre-built releases of Knative, Tekton, KEDA, Sigstore Policy Controller, or Kpack where patched upstream container images are not immediately deployed, the primary compensating control is network isolation via Kubernetes NetworkPolicy. Because only the Kubernetes API server (kube-apiserver) has a legitimate need to communicate with admission webhook pods, operators should block all intra-cluster pod-to-webhook traffic.

Below is an example NetworkPolicy that restricts ingress traffic to the webhook port (8443) so that only the control plane API server CIDR can establish connections:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-webhook-ingress
  namespace: knative-serving # Replace with target controller namespace (e.g., tekton-pipelines, keda)
spec:
  podSelector:
    matchLabels:
      app: webhook # Replace with the specific label selector for the webhook pod
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 10.0.0.10/32 # Replace with the kube-apiserver IP/CIDR
      ports:
        - protocol: TCP
          port: 8443

Additionally, if the webhook deployment supports mutual TLS (mTLS) configuration, enforcing strict client certificate authentication (tls.RequireAndVerifyClientCert) verified against the Kubernetes API server's client CA prevents unauthenticated cluster pods from completing the TLS handshake and reaching the HTTP handler.