CVE-2026-88979

Kubeflow TensorBoard proxy signs tokens with a public default

Kubeflow · Kubeflow Pipelines TensorBoard proxy

First documented disclosure · Review checkpoint

Summary

A known default signing key permits forged tokens selecting an internal service.

Severity and exploitation evidence

Medium · 5.8/10 · CVSS 3.1. Severity source.

Exploitation not established: A controlled handler reproduction is documented; unrestricted metadata access, credential theft and malicious exploitation are not established.

Exploitation evidence source

Technical severity is not a measure of observed attacks or of risk to your deployment. Attempts, demonstrations, and successful compromise retain the qualifications in the source.

How the weakness works

The proxy derives its HMAC key from an object-store credential whose bundled value is public.

Conditions required

Reachable frontend with authorization disabled and the bundled default signing key; a matching internal service must exist.

Potential impact

Constrained HTTP response disclosure on port 80 through the TensorBoard service/path pattern. Namespace authorization remains effective when enabled.

Affected versions and configurations

KFP 2.17.0 through 2.17.3.

Fix and mitigation status

2.18.0 uses a dedicated strong signing key.

Practical next steps

Upgrade with matching manifests; preserve the dedicated signing Secret and verify all replicas use it. Reopen TensorBoard links after the initial key transition. Do not reuse storage credentials.

Operating lesson

A signed token has no security value if its signing key is public.

Evidence and limits

September 9 public fix; October 28 advisory/release; November 5 CNA. This is a new flaw introduced by the prior TensorBoard remediation, not an extension of the older CVE’s affected range. Custom process-local keys lack restart/multi-replica continuity.

Sources