Description

Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the frontend GET /artifacts/get route accepts source=http or source=https with caller-controlled bucket and key values, and isAllowedResourceName permits an all-digit decimal host that the URL parser converts to an IPv4 address. The default ALLOWED_ARTIFACT_DOMAIN_REGEX and authorization-disabled standalone configuration allow an unauthenticated caller to fetch internal HTTP resources and receive their response body. In the authenticated multi-user configuration, the same destination-validation defect is reachable by a low-privilege tenant with a valid identity and authorized namespace. Cloud credential disclosure depends on reachable metadata services and attached roles, and the issue does not establish IMDSv2 bypass or credential access when metadata is blocked. This issue is fixed in version 2.18.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.6",
  "pubDate": "2026-11-05T23:17:01.277Z",
  "pubdate": "2026-11-05T23:17:01.277Z",
  "executiveSummary": "Kubeflow Pipelines versions prior to 2.18.0 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability within the frontend GET /artifacts/get route.\nThe flaw stems from insufficient input validation of the source parameter, allowing attackers to manipulate bucket and key parameters.\nBy providing an all-digit decimal host, an attacker can bypass the isAllowedResourceName check due to URL parser behavior that resolves these inputs into IPv4 addresses.\nThis permits unauthenticated or low-privilege users to perform requests against internal HTTP services, potentially leading to unauthorized data exfiltration.\nThe impact depends on the environment's network configuration and the presence of accessible metadata services; however, the vulnerability does not inherently bypass IMDSv2 protections.\nOrganizations using standalone, authorization-disabled, or multi-user configurations are at risk until the patch is applied.",
  "technicalDetails": "The vulnerability resides within the frontend service of Kubeflow Pipelines, specifically in the logic handling the GET /artifacts/get route. The application incorrectly processes the source parameter (supporting http/https schemes) by relying on flawed validation logic within the isAllowedResourceName function.\nThe root cause is a discrepancy between URL parsing and domain validation. The isAllowedResourceName function permits decimal-formatted IP addresses, which are interpreted by the underlying URL parsing library as valid IPv4 addresses. Because the default ALLOWED_ARTIFACT_DOMAIN_REGEX does not strictly blacklist internal IP ranges or loopback interfaces, the application can be coerced into initiating outbound requests to arbitrary internal network resources.\nIn a standalone, authorization-disabled deployment, an unauthenticated attacker can supply crafted HTTP/HTTPS URLs pointing to internal endpoints to retrieve sensitive response bodies. In authenticated multi-user deployments, a low-privilege tenant within an authorized namespace can leverage this defect to conduct internal reconnaissance or interact with internal APIs that trust the Kubeflow frontend service.\nThe attack flow proceeds as follows: 1) The attacker identifies the GET /artifacts/get route as a target. 2) The attacker crafts a request containing a source parameter with an all-digit decimal IP (e.g., 169.254.169.254). 3) The application’s validation routine fails to identify this as a prohibited internal host. 4) The frontend service performs an outbound request to the specified IP. 5) The response from the internal service is returned to the attacker. 6) The attacker parses the response to extract configuration data, internal metadata, or other sensitive information.\nWhile the vulnerability is severe, it is limited by the environment's network posture. If internal services require specific headers or are protected by IMDSv2, the utility of this SSRF is significantly reduced, as the vulnerability does not inherently perform the cryptographic signing required to bypass IMDSv2. Nevertheless, the risk remains high for environments where internal services lack robust authentication, as it provides a gateway to traverse network segments that are not exposed to the public internet."
}