What happened
Kubeflow Pipelines trusts attacker-supplied object-store endpoint metadata in the artifact-download and pod-log paths instead of validating against operator-controlled storage configuration. In the default authorization-disabled standalone setup this allows SSRF from the shared ml-pipeline-ui pod to internal services, and can disclose an access-key identifier when requests are signed with configured object-store credentials.
Why it matters
ML workflow infrastructure is often deployed with a shared UI pod trusted to reach internal services; this SSRF can be used for internal network reconnaissance or to move toward the object-store credential, undermining the isolation between the pipeline UI and the rest of the ML platform.
Attack vector
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 config. An unauthenticated caller can make the shared ml-pipeline-ui pod send requests to arbitrary reachable hosts and return response data; signed requests may reveal an access-key identifier.
Affected systems
Kubeflow Pipelines < 2.18.0
Mitigation
Upgrade to Kubeflow Pipelines 2.18.0. Advisory: https://github.com/kubeflow/pipelines/security/advisories/GHSA-3pcj-8j5w-jmxq