knative.dev/pkg admission webhooks allow unbounded request-body memory exhaustion
- Exploited
- Proof of concept public, per CISA
- Fix
- Fixed in 0.0.0-20260531000007-52dbd5ece63f
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 0.0.0-20260531000007-52dbd5ece63f.
- Last modified
- FIRST's estimate of the chance attackers exploit it in the next 30 days, updated daily.What do these mean? →
- 0.38% · 31st percentile
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 35/100
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: poc
- Automatable: no
- Technical impact: partial
Summary
The knative.dev/pkg admission webhook server, which many Kubernetes projects share, can be made to use unlimited memory by a single oversized request from within the cluster network. This can crash the controller pod, which may block admissions for dependent projects such as Knative, Tekton, KEDA, Sigstore policy-controller, and Kpack.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
Knative pkg provides common packages shared across Knative repositories. Prior to 0.0.0-20260531000007-52dbd5ece63f, the knative.dev/pkg/webhook admissionHandler in webhook/admission.go decodes an attacker-supplied AdmissionReview through json.NewDecoder(io.TeeReader(r.Body, &bodyBuffer)) under an http.HandlerFunc without an http.MaxBytesReader or equivalent body-size limit. A pod-network client can send one oversized POST to an admission webhook, causing the decoder and bodyBuffer to retain amplified copies of the request until the controller pod exhausts memory and is OOM-killed. Every downstream consumer using the shared webhook server inherits the vulnerable behavior, including Knative, Tekton, KEDA, Sigstore policy-controller, and Kpack. For consumers configured with failurePolicy=Fail, loss of the controller can interrupt admission; with failurePolicy=Ignore, the affected webhook is unavailable while other admissions continue. This issue is fixed in version 0.0.0-20260531000007-52dbd5ece63f.
cve.now Index
- Exploitation15/40CISA rates a proof of concept as public
- Exposure3/25Reachable over the network · Unknown: No advisory context yet
- Reach10/20Affects Go packages
- Severity6.5/10CVSS 6.5
- No patch0/5No signal
What would change the score
- Would score about 75 if added to CISA KEV
- Would score about 70 if CISA's SSVC rates exploitation active
- Would score about 54 if advisories confirm default setups are exposed
What to do
Upgrade to a fixed version: 0.0.0-20260531000007-52dbd5ece63f.
Timeline
- CVE published
- First seen by cve.now6 days
- CISA SSVC assessment
Exploitation: poc · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- knative pkg
fixed in 0.0.0-20260531000007-52dbd5ece63f
- knative.dev/pkgGo
fixed in 0.0.0-20260531000007-52dbd5ece63f
Evidence 3
- Advisory
- Repository
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-54462
Is CVE-2026-54462 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. CISA's SSVC assessment notes a proof of concept exists. No public exploit code is tracked.Source: cve.now feed data
Which versions are affected by CVE-2026-54462?
pkg: before 0.0.0-20260531000007-52dbd5ece63f. knative.dev/pkg (Go): before 0.0.0-20260531000007-52dbd5ece63f.Source: cve.now feed data
How do I fix CVE-2026-54462?
Upgrade to a fixed version: 0.0.0-20260531000007-52dbd5ece63f.Source: cve.now feed data