Kubeflow Pipeline Archives Put Memory Limits Before Authorization

Kubeflow Pipelines 2.18.0 fixes CVE-2026-118761, a high-severity resource-exhaustion flaw in the API server. A small ZIP or gzip-compressed tar pipeline archive can expand far beyond its compressed size while the server searches for or reads the pipeline specification. A reachable multipart upload can consume enough memory to interrupt the API service before namespace authorization decides whether the caller may create the pipeline.

The project lists kfp-api-server versions through 2.17.3 as affected and 2.18.0 as fixed, while noting that the first affected release has not been established. The patch bounds both selected file reads and total archive traversal, including skipped entries and metadata. Operators should upgrade the running API-server image, restrict upload reachability, test legitimate archives against the new limits, and keep independent controls for HTTP bodies, concurrency, CPU, temporary storage, and pod memory.

Kubeflow published GHSA-8fmv-6rg5-5924 on October 29, and GitHub reviewed the advisory on October 30. It assigns CVE-2026-118761 a 7.5 CVSS 3.1 score with network access, low complexity, no privileges, and no user interaction. The affected software is the Kubeflow Pipelines API-server image. Versions through 2.17.3 are affected, and 2.18.0 is the published fixed boundary.

The version statement has one important uncertainty: the project has not established the first affected release. An operator should not convert that into an assumption that an old deployment is safe. Inventory the exact API-server image, digest, deployment manifest, and any platform distribution that repackages it. If the running component is at or below 2.17.3 and exposes the relevant handlers, treat it as affected until the distributor says otherwise.

The advisory limits the confirmed security impact to availability. It does not claim that an archive can read pipeline secrets, change another tenant's objects, or execute code. It also does not report exploitation in the wild. Those boundaries keep a denial-of-service response proportionate while still recognizing that an API outage can stop submissions, schedules, and operational access to a shared machine-learning platform.

The vulnerable sequence matters more than the file extension. Multipart handlers for pipeline and pipeline-version uploads accept an archive and decompress it while locating or reading the pipeline file. Only after that work does namespace authorization determine whether the caller may create the object. A request that will eventually be denied can therefore consume significant server resources first.

The advisory says a caller who can reach those upload endpoints does not need a successful pipeline-create authorization decision to trigger the issue. That is not identical to universal internet exposure. An independent authentication proxy, service mesh policy, private network, or ingress rule can prevent an untrusted caller from reaching the handler. Teams must examine the path in front of the API server rather than treating the advisory's `PR:N` metric as proof of their deployment topology.

URL-based import follows a different sequence: those handlers authorize before fetching and decompressing a remote archive. Do not collapse every pipeline ingestion route into one exposure statement. The multipart upload path is the confirmed pre-authorization route, while import still needs normal URL-fetch and resource controls after authorization.

Pull request 14171 documents the central failure. The API server bounded the uploaded compressed file at 32 MB, but its ZIP and tar decompression helpers used `io.ReadAll()` on the expanded content without a corresponding uncompressed limit. Highly repetitive input can be tiny on the wire and enormous after expansion. The pull request notes that a permitted archive could grow to gigabytes in memory and drive the process into an out-of-memory failure.

A second path shows why limiting only the selected file is incomplete. The metrics parser used a gzip and tar reader to scan an archive until it found the desired entry. Although the selected metrics file had a size bound, the reader could still traverse gigabytes of compressible padding, metadata, or decoy entries first. That work consumes CPU and memory even when the useful file remains small.

Resource accounting therefore has to follow the full parser. Count compressed bytes accepted, expanded bytes produced, headers and metadata traversed, entries skipped, time spent, temporary files, concurrent parsers, and process memory. A check placed after expansion or only around the final extracted object leaves an earlier amplification stage unbounded.

Kubeflow Pipelines 2.18.0 was released on October 28 and includes archive and request-size hardening among a broader set of security improvements. The primary archive correction threads the configured maximum into decompression helpers, wraps readers with an additional byte of headroom to detect overflow, and returns an invalid-input error when expanded pipeline content exceeds the allowed size.

The companion correction places a traversal budget around the underlying gzip reader used by tar processing. That budget counts bytes consumed while moving between entries, not only bytes returned for the file the application wanted. Regression coverage exercises compressed input, selected-entry limits, and traversal exhaustion. The advisory notes that the assessment did not perform a deployed-server out-of-memory test, so the evidence demonstrates bounded code paths rather than a claim about every production configuration.

The release also makes upload and specification limits configurable. Operators should review the values they actually deploy instead of inheriting defaults blindly. The project explicitly says these controls do not establish general limits for HTTP bodies, temporary disk, concurrency, or CPU. Treat 2.18.0 as the required application fix and keep platform-level resource controls around it.

If an immediate upgrade is not possible, place an independent authentication and authorization gate before the multipart upload routes. Remove direct public service exposure, restrict ingress to approved users or automation networks, and verify that alternate hosts, legacy gateways, port forwards, and development endpoints cannot reach the API server. A namespace denial inside Kubeflow occurs too late for this flaw.

Apply request-rate and concurrency controls at the ingress, and give the API-server pod a deliberate memory limit with alerts on pressure, restart counts, and `OOMKilled` events. Those measures can reduce blast radius but may turn one expensive request into repeated restarts if the handler remains reachable. Keep control-plane components separate from user workloads where possible, and make sure liveness behavior does not amplify a memory event into an endless crash loop.

Do not rely on a compressed body limit alone. A gateway that accepts a 32 MB upload has not bounded its expanded representation. Monitor rejected uploads, latency and resident-memory jumps during archive handling, repeated pipeline-version calls, source identities, and error bursts. Preserve ingress, API-server, Kubernetes event, and container-runtime evidence if unexplained restarts already occurred.

Deploy Kubeflow Pipelines 2.18.0 or a distributor build that explicitly includes the correction. Verify the image digest running in every API-server replica after rollout. Updating an SDK, notebook image, or pipeline compiler does not prove the backend changed. Remove old replicas and rollback targets that can return the vulnerable server during an autoscaling or recovery event.

Test representative ZIP and gzip-compressed tar pipelines before broad deployment. Include legitimate specifications near the configured limit, archives with extra entries and metadata, pipeline-version uploads, and client error handling when the server rejects an oversized expansion. Select limits from real workload measurements and a documented server memory budget, then keep enough margin for concurrent requests and normal control-plane work.

Finally, review upload processing as a reusable service boundary. Parse untrusted archives in a constrained worker when practical, stream rather than buffering whole objects, stop on total expanded and traversal budgets, limit entry count and nesting, and separate authorization from expensive parsing. The immediate CVE is fixed in 2.18.0; those design rules prevent the same amplification pattern from reappearing in artifact, model, log, or metrics ingestion.