CVE-2026-118760: Kubeflow Pipelines: missing authz exposes tenant artifacts
MEDIUMKubeflow Pipelines before 2.17.0 does not check whether an authenticated user is allowed to read artifacts from the namespace they request, so any user who can reach the frontend and knows an artifact location can read another tenant's datasets, models, or pipeline outputs. The flaw is rated medium (CVSS 6.5, high confidentiality impact only), but in a multi-tenant ML platform the data at stake is often proprietary training data and model IP, so the business impact can exceed the score. There is no public exploit, no Nuclei template, no KISS/KEV listing and no EPSS score yet, so likelihood looks low today; the main prerequisites are a valid low-privilege account and knowledge of an artifact path, which insiders or other tenants may well have. Upgrade to Kubeflow Pipelines 2.17.0 and, until then, restrict frontend access and review artifact access logs for cross-namespace reads.
What is the risk?
Medium overall. Exploitation is network-based, low complexity, needs only low privileges and no user interaction, but the attacker must know an artifact location. Impact is confined to confidentiality (CVSS C:H/I:N/A:N). The advisory states it does not give arbitrary Kubernetes Secret disclosure, storage modification, or code execution. Risk is highest in shared multi-user deployments that depend on Kubeflow Pipelines authorization for tenant isolation. Single-tenant installs are largely unaffected. No exploitation evidence, public PoC, or EPSS data is available at publication.
How does the attack unfold?
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade Kubeflow Pipelines to 2.17.0 or later (fix in PR 12860 / commit fb69119). 2) Until patched, restrict network reachability of the Pipelines frontend to trusted users and apply network policies or ingress rules that block direct access to the artifact handlers. 3) Enforce namespace-aware authorization at the ingress or service mesh layer (for example, Istio AuthorizationPolicy) rather than authentication alone. 4) Review frontend and object-storage access logs for artifact requests that omit the namespace parameter or reference another namespace. 5) Use per-tenant storage buckets or prefixes with separate credentials where possible, and rotate or reclassify any data suspected of exposure.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-118760?
Kubeflow Pipelines before 2.17.0 does not check whether an authenticated user is allowed to read artifacts from the namespace they request, so any user who can reach the frontend and knows an artifact location can read another tenant's datasets, models, or pipeline outputs. The flaw is rated medium (CVSS 6.5, high confidentiality impact only), but in a multi-tenant ML platform the data at stake is often proprietary training data and model IP, so the business impact can exceed the score. There is no public exploit, no Nuclei template, no KISS/KEV listing and no EPSS score yet, so likelihood looks low today; the main prerequisites are a valid low-privilege account and knowledge of an artifact path, which insiders or other tenants may well have. Upgrade to Kubeflow Pipelines 2.17.0 and, until then, restrict frontend access and review artifact access logs for cross-namespace reads.
Is CVE-2026-118760 actively exploited?
No confirmed active exploitation of CVE-2026-118760 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-118760?
1) Upgrade Kubeflow Pipelines to 2.17.0 or later (fix in PR 12860 / commit fb69119). 2) Until patched, restrict network reachability of the Pipelines frontend to trusted users and apply network policies or ingress rules that block direct access to the artifact handlers. 3) Enforce namespace-aware authorization at the ingress or service mesh layer (for example, Istio AuthorizationPolicy) rather than authentication alone. 4) Review frontend and object-storage access logs for artifact requests that omit the namespace parameter or reference another namespace. 5) Use per-tenant storage buckets or prefixes with separate credentials where possible, and rotate or reclassify any data suspected of exposure.
What systems are affected by CVE-2026-118760?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, ML workflow orchestration, multi-tenant ML platforms, model registries and artifact stores.
What is the CVSS score for CVE-2026-118760?
CVE-2026-118760 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.35%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0007Discover AI ArtifactsAML.T0012Valid AccountsAML.T0025Exfiltration via Cyber MeansAML.T0035AI Artifact CollectionCompliance Controls Affected
What are the technical details?
Original Advisory
Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. From 0.5.1 until 2.17.0, the frontend artifact routes did not check whether an authenticated user was authorized to access the requested namespace. A user who can reach the frontend and knows an artifact location can select another tenant's namespace, or omit the namespace and reach an unguarded direct handler, to read artifact contents such as datasets, models, or pipeline outputs. The issue applies to multi-user deployments that rely on Kubeflow Pipelines authorization for tenant isolation. Authentication at ingress identifies the caller but does not authorize access to the selected artifact namespace. The issue does not establish arbitrary Kubernetes Secret disclosure, storage modification, or server-side code execution. This issue is fixed in version 2.17.0.
Exploitation Scenario
An authenticated data scientist in one team's namespace learns or guesses the object-storage path of another team's artifact, for example from a shared URL, a log, or a predictable naming pattern. They call the Pipelines frontend artifact route while selecting the victim's namespace, or omit the namespace entirely to reach the unguarded direct handler. The frontend returns the artifact without an authorization check, letting the attacker download proprietary datasets, trained model files, or pipeline outputs and exfiltrate them for competitive or monetary gain.
Weaknesses (CWE)
CWE-639Authorization Bypass Through User-Controlled KeyPrimaryCWE-862Missing AuthorizationPrimaryCWE-639Authorization Bypass Through User-Controlled KeyCWE-862Missing AuthorizationCWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
- [Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- [Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NReferences
Timeline
Related Vulnerabilities
CVE-2025-512010.0smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Data LeakageCVE-2025-5376710.0Azure OpenAI: SSRF EoP, no auth required (CVSS 10)
Same attack type: Data ExtractionCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same attack type: Data LeakageCVE-2025-282810.0LangChain RequestsToolkit: SSRF exposes cloud metadata
Same attack type: Data ExtractionCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same attack type: Data Extraction