Copyright © 2012 Red Hat, Inc. All rights reserved. Moderate 2026-11-05T22:14:38 github.com/kubeflow/pipelines: Kubeflow Pipelines: Information disclosure via default proxy signing key 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-1392

Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. From 2.17.0 until 2.18.0, the TensorBoard proxy token introduced by the incomplete remediation for CVE-2026-54745 uses MINIO_SECRET_KEY as its HMAC secret, whose bundled default is publicly known. In an authorization-disabled deployment using that default, an unauthenticated attacker can forge a token containing a chosen viewerName and namespace; the proxy constructs the destination from the viewerName plus the -service suffix, the namespace, and the configured cluster domain, then reads responses on port 80 under the /tensorboard/<viewer>/ path. Resource-name validation and path-traversal rejection remain enforced, authorization-enabled deployments still check access to the selected namespace, and unrestricted metadata access, writes, or service disruption are not established. This issue is fixed in version 2.18.0.

A flaw was found in Kubeflow Pipelines. The TensorBoard proxy relies on a publicly known default secret key to sign authentication tokens. In deployments where authorization is disabled, an unauthenticated remote attacker can forge authentication tokens to query internal cluster services on port 80 and read their responses. This vulnerability leads to unauthorized information disclosure from internal network resources.

This vulnerability is rated as Moderate impact because exploitation requires an authorization-disabled configuration using default signing keys, and the resulting exposure is restricted to read-only queries against specific internal services. In standard Red Hat OpenShift environments, cluster-level authorization and role-based access control are enabled by default, ensuring that namespace validation blocks unauthorized access. Furthermore, built-in validation controls limit destination endpoints and reject directory traversal attempts, preventing broader network access or modification of cluster resources. To mitigate this flaw: 1. Enable authorization: Configure Kubeflow Pipelines to run with authorization enabled, ensuring that access to target namespaces is verified before requests are proxied. 2. Replace default secrets: Supply a distinct, cryptographically strong value for the MINIO_SECRET_KEY environment variable or Kubernetes Secret rather than leaving the bundled default. 3. Apply network controls: Deploy Kubernetes NetworkPolicies to restrict ingress traffic on port 80 for internal services, limiting connections solely to authorized application components. Warning: Modifying deployment environment variables or cluster secrets requires recreating or restarting the affected pods, which will cause a brief disruption to active pipeline workloads. Red Hat OpenShift AI (RHOAI) Under investigation rhoai/odh-ml-pipelines-api-server-v2-rhel9 Red Hat OpenShift AI (RHOAI) Under investigation rhoai/odh-ml-pipelines-driver-rhel9 Red Hat OpenShift AI (RHOAI) Under investigation rhoai/odh-ml-pipelines-launcher-rhel9 Red Hat OpenShift AI (RHOAI) Under investigation rhoai/odh-ml-pipelines-persistenceagent-v2-rhel9 Red Hat OpenShift AI (RHOAI) Under investigation rhoai/odh-ml-pipelines-scheduledworkflow-v2-rhel9 https://www.cve.org/CVERecord?id=CVE-2026-88979 https://nvd.nist.gov/vuln/detail/CVE-2026-88979 https://github.com/kubeflow/pipelines/commit/c8effaed62476a8d8c99d3a6cfdd404a04ef99d8 https://github.com/kubeflow/pipelines/pull/14346 https://github.com/kubeflow/pipelines/releases/tag/2.18.0 https://github.com/kubeflow/pipelines/security/advisories/GHSA-j429-j7xw-8j9h