CVE-2026-118761High· 7.5▾ TwilightKubeflow Pipelines: Pipeline archive upload allows decompression bomb to exhaust server memory
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Oct 31.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
0.5%
The Kubeflow Pipelines API server decompresses uploaded pipeline archives without adequately bounding expanded data in affected versions. A small ZIP or gzip-compressed tar archive can consume disproportionately large amounts of memory while the server locates or reads the pipeline file, potentially exhausting API-server resources and interrupting service.
Multipart pipeline and pipeline-version upload processing decompresses the archive before namespace authorization, so a caller who can reach those endpoints does not need a successful pipeline-create authorization decision to trigger the issue. External authentication and network controls can restrict reachability. URL-import handlers authorize before fetching and decompressing a remote archive.
The amount of expansion needed to exhaust memory depends on deployment resource limits and concurrent activity; no particular archive is guaranteed to crash every deployment.
Upgrade the API server to Kubeflow Pipelines 2.18.0. Versions through 2.17.3 are affected; the first affected release has not been established.
PR #14171 bounds compressed input and extracted pipeline data. PR #14186 strengthens the total tar traversal budget, including metadata and skipped entries. The 2.18 release also includes configurable upload and specification limits; operators should review the shipped settings and resource budget. These controls address pipeline archive amplification and do not establish general HTTP-body, temporary-disk, concurrency, or CPU limits.
Until upgrading, restrict access to upload and import endpoints and apply deployment-level request and resource controls. A compressed upload-size limit alone does not prevent decompression amplification. Regression tests cover compressed input, selected-entry boundaries, and tar traversal budgets; no deployed-server OOM test was performed for this assessment.
bugbunny.ai discovered and reported the issue. Ayush Gupta (@Ayush-kathil) authored the archive fixes in #14171 and #14186, with Jeff Spahr (@jeffspahr) contributing regression coverage to #14171.
@BrianWillows later submitted a mixed report that included source analysis of pipeline-archive decompression.
github.com/kubeflow/pipelines < 0.0.0-20260831164314-ba9ae72cc860github.com/kubeflow/pipelinesUpgrade to a patched release:
github.com/kubeflow/pipelines 0.0.0-20260831164314-ba9ae72cc860Connected by shared product, vendor, weakness, or advisory.
CVE-2026-118759High· 7.5Kubeflow Pipelines: Run-log endpoint permits unauthorized access to pod logs
CVE-2026-118758High· 7.5Kubeflow: Unauthenticated path traversal to arbitrary file read on ml-pipeline-ui via the volume artifact source
CVE-2026-118261HighEcho: Decompress permits unbounded gzip expansion in v4
GHSA-h7wr-284f-5qvcHighEcho: Decompress permits unbounded gzip expansion in v4
CVE-2026-91979Medium· 6.5Vikunja before 2.6.0 fails to limit archive expansion during data import, allowing authenticated users to cause denial of service
CVE-2026-8814Medium· 5.3Versions of the package exifreader before 4.39.0 are vulnerable to Improper Handling of Highly Compressed Data (Data Amplification) due to decompressing PNG zTXt metadata without enforcing a built-in maximum decompressed output size