Kubeflow Pipelines: Unauthenticated SSRF through artifact provider endpoints
Affects Kubeflow Pipelines frontend 2.17.3 and earlier in standalone deployments with authorization disabled, the shipped configuration. Fixed in 2.18.0.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 2.18.0
- Who is exposed
- Default setups
Do first: Check every install: default setups are affected.
- Last modified
- 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? →
- 31/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Default setups
- 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
Summary
Kubeflow Pipelines contains a server-side request forgery flaw in its artifact download and pod-log paths, which in the default standalone setup lets an unauthenticated attacker remotely make the shared ml-pipeline-ui pod connect to arbitrary reachable hosts and return the response data. The issue is fixed in a later release.
Read the original description
Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the frontend artifact download path for source=s3 or source=minio accepts providerInfo.Params.endpoint, and the archived pod-log path accepts S3-compatible endpoint metadata from workflow status, without requiring those endpoints to match operator-controlled storage configuration. In the shipped authorization-disabled standalone configuration, an unauthenticated caller can make the shared ml-pipeline-ui pod connect to arbitrary reachable hosts and return response data; requests may also reveal an access-key identifier when signed with configured object-store credentials. Multi-user secret-backed metadata remains restricted to the server namespace. This issue is fixed in version 2.18.0.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure22/25Default setups, reachable over the network without a login
- Reach?/20Unknown. No tracked technology or package matched
- Severity8.6/10CVSS 8.6
- No patch0/5No signal
What would change the score
- Would score about 71 if added to CISA KEV
- Would score about 66 if CISA's SSVC rates exploitation active
What to do
Check every install: default setups are affected.
Upgrade to a fixed version: 2.18.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- kubeflow pipelines
fixed in 2.18.0
Evidence 4
- Advisory
- Repository
- Repository
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-88981
Is CVE-2026-88981 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. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
An unauthenticated user can make the ml-pipeline-ui pod send requests to internal, loopback, or link-local hosts and return the responses, which can include internal service data and cloud metadata. Requests may also be signed with configured object-store credentials, exposing an access-key identifier to an attacker-controlled endpoint.Source: github.com
Which versions are affected by CVE-2026-88981?
pipelines: before 2.18.0.Source: cve.now feed data
Am I affected, and how do I check?
The affected product is the Kubeflow Pipelines frontend (ghcr.io/kubeflow/kfp-frontend) at version 2.17.3 or earlier, in standalone deployments with authorization disabled, as the shipped configuration sets. The artifact download path with source=s3 or source=minio and archived pod-log retrieval using S3-compatible artifact-repository metadata from Argo workflow status are both affected. To check a deployment, look at the frontend image version and the authorization setting in its configuration.Source: github.com
How do I fix CVE-2026-88981?
Upgrade the Kubeflow Pipelines frontend to 2.18.0, which includes the fix.Source: github.com