Knative pkg EUVD-2026-111135

Exploitation requires network reachability to the admission webhook HTTP(S) endpoint (commonly port 8443) of a controller that embeds knative.dev/pkg/webhook with the vulnerable admissionHandler - i.e. a deployed Knative, Tekton, KEDA, Sigstore policy-controller, or Kpack webhook server using a vulnerable pkg version. No authentication to the application and no user interaction are needed beyond sending an oversized POST to the webhook path; the CVSS PR:L reflects the attacker needing a foothold on the pod/cluster network rather than application credentials. The severity of the outcome is limited and shaped by two deployment factors stated in the evidence: the pod's memory limit (a lower limit OOMs with a smaller body - e.g. a 512 MiB pod can be killed with ~128 MiB), and the webhook's failurePolicy - failurePolicy=Fail turns the OOM into a cluster/namespace admission outage, while failurePolicy=Ignore only takes that one webhook offline while other admissions proceed.

This is a genuine but bounded availability-only issue, best characterized as a medium-priority service-disruption flaw rather than a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, 6.5 MEDIUM) correctly captures a network-reachable, low-complexity attack with only availability impact (A:H) and no confidentiality or integrity loss. The vuln.today decision label is 'this_month', consistent with a serious-but-not-drop-everything DoS. No EPSS score was provided and the CVE is not listed in CISA KEV, so there is no signal of widespread or active exploitation - treat exploitation status as 'no public exploit identified' except that the GHSA advisory itself references a reporter-built PoC (cmd/poc-c2/main.go) demonstrating ~4.5× memory amplification; that PoC is described as 'available on request' and is not verified as packaged, working public exploit code. The main thing elevating real-world concern is breadth of inheritance, not sophistication: because the vulnerable handler lives in the shared knative.dev/pkg webhook library, every downstream consumer (Knative, Tekton, KEDA, Sigstore policy-controller, Kpack) inherits it, and for consumers running failurePolicy=Fail the controller OOM can translate into a cluster- or namespace-wide admission outage. No conflicting signals were found between the vector and the description - both point to a remote, low-privilege, availability-only DoS. The GHSA note that this could be argued as HIGH 7.5+ is a scoping opinion (library-wide vs per-consumer) and is not reflected in the assigned 6.5; defenders should weight their own exposure by how many affected controllers they run and their failurePolicy settings.

An attacker with access to the pod/cluster network sends a single oversized POST (e.g. a multi-hundred-MiB or multi-GiB JSON body) to the admission webhook port (typically 8443) of any controller built on knative.dev/pkg, such as a Tekton or Knative webhook. The handler decodes the body through json.NewDecoder(io.TeeReader(r.Body, &bodyBuffer)) with no http.MaxBytesReader, so the decoder and the tee'd bodyBuffer retain amplified copies - the reporter observed ~4.5× the body size - until the pod exceeds its memory limit and is OOM-killed. A reporter PoC reference exists but is not verified as working public exploit code; the attack requires only low complexity and pod-network reachability.