Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.8",
  "pubDate": "2026-11-05T23:17:01.110Z",
  "pubdate": "2026-11-05T23:17:01.110Z",
  "executiveSummary": "A critical security vulnerability exists in Kubeflow Pipelines versions 2.17.0 through 2.18.0, stemming from an insecure cryptographic implementation within the TensorBoard proxy mechanism. The vulnerability is a consequence of an incomplete remediation for CVE-2026-54745, where the system utilizes the MINIO_SECRET_KEY as the HMAC secret for token generation.\nIn deployments where the default MinIO secret is retained, the secret is effectively publicly known, enabling an unauthenticated attacker to forge valid authentication tokens. This allows an attacker to bypass authorization checks in configurations where access control is otherwise disabled. By crafting a malicious token containing a specific viewerName and namespace, the attacker can manipulate the proxy into routing requests to arbitrary services within the cluster.\nWhile the vulnerability does not grant direct write access, metadata modification, or service disruption capabilities, it facilitates unauthorized reading of responses from internal TensorBoard services. The risk is significant in environments relying on default configurations or those lacking robust identity and access management for internal service communication. Users are advised to upgrade to version 2.18.0 immediately to mitigate the risk of unauthorized information disclosure.",
  "technicalDetails": "The vulnerability resides in the TensorBoard proxy component of Kubeflow Pipelines. The root cause is the reliance on a static, predictable cryptographic secret—specifically the MINIO_SECRET_KEY—to sign HMAC tokens used for session validation. This implementation flaw was introduced as an incomplete remediation for the security issue tracked under CVE-2026-54745.\nThe attack flow begins when an attacker identifies a deployment of Kubeflow Pipelines 2.17.0 using the bundled, default MinIO configuration. Because the MinIO secret is known or easily discoverable in these default installations, an attacker can programmatically generate a valid HMAC token. The token structure requires a 'viewerName' and a target 'namespace'. Upon submission of this forged token, the proxy service fails to verify the integrity and authenticity of the token effectively, as the underlying secret key matches the attacker's knowledge.\nOnce the proxy accepts the forged token, it constructs a destination URI using the format derived from the 'viewerName' + '-service' suffix, the targeted 'namespace', and the cluster's internal domain. The proxy then performs an authenticated request to the internal TensorBoard service on port 80, specifically targeting paths under '/tensorboard/<viewer>/'.\nExploitation is constrained by existing security mechanisms; the system enforces resource-name validation and rejects path-traversal attempts. Furthermore, if the deployment has active authorization enabled, the system still verifies the attacker's permissions regarding the target namespace, which may limit the scope of the exposure. In authorization-disabled deployments, however, the attacker gains the ability to perform unauthorized reads of TensorBoard response data from services they are not otherwise authorized to access.\nThis vulnerability is restricted to the proxy's interaction with the TensorBoard interface and does not escalate to arbitrary code execution, unauthorized write operations, or broader cluster disruption. The attack vector requires network access to the proxy endpoint, and the potential impact is limited to the unauthorized viewing of sensitive information processed or displayed within the TensorBoard instance. This issue is fully resolved in version 2.18.0, which enforces a more secure mechanism for token management."
}