CVE-2026-88986: Reflected Cross-Site Scripting in Kubeflow Pipelines Frontend Error Responses

Kubeflow Pipelines is a platform for building and deploying portable, scalable machine learning (ML) workflows based on Docker containers within Kubernetes environments. The platform includes a web-based user interface (kfp-frontend) built on Node.js and Express, which acts as an intermediary between the user's browser and the underlying Kubernetes API and pipeline backend services. This frontend server exposes several internal proxy and helper endpoints that allow users to inspect the execution state, logs, and Kubernetes events of individual pods corresponding to pipeline steps.

In Kubeflow Pipelines versions prior to 2.15.0, the frontend server endpoints /pipeline/k8s/pod and /pipeline/k8s/pod/events contain a reflected Cross-Site Scripting (XSS) vulnerability, tracked as CVE-2026-88986 (GHSA-g3qx-frcg-j979) and classified under CWE-79 (Improper Neutralization of Input During Web Page Generation). When processing client requests to retrieve pod details or associated cluster events, the backend helper routines in frontend/server/k8s-helper.ts take user-supplied query parameters—specifically podname and podnamespace—and pass them to the Kubernetes client API.

When the Kubernetes API call fails (for example, when querying a non-existent pod or an invalid namespace format), the error handling logic constructs a diagnostic message containing the raw, unvalidated podname and podnamespace values alongside the backend error string. The Express application then returns this string directly in the HTTP 500 response body via res.status(500).send(err.message).

Because Express defaults to a Content-Type of text/html when sending string responses without an explicit MIME type override, the victim's web browser interprets the error response as an HTML document. Consequently, any HTML markup or JavaScript payloads injected into the query parameters are parsed and executed within the security context of the Kubeflow frontend origin.

The root cause of CVE-2026-88986 is the combination of missing input validation on Kubernetes resource identifiers, unsafe string interpolation in error catch blocks, and reliance on Express's default text/html content-type assignment in res.send().

When an HTTP GET request reaches /pipeline/k8s/pod or /pipeline/k8s/pod/events, the Express route handlers extract podname and podnamespace from req.query. Prior to version 2.15.0, the server did not verify whether these strings conformed to Kubernetes resource naming conventions (such as RFC 1123 DNS label standards, which restrict names to lowercase alphanumeric characters and hyphens). Instead, arbitrary strings containing HTML control characters (<, >, ", ') were passed directly to getPod(podName, podNamespace) or listPodEvents(podName, podNamespace) inside frontend/server/k8s-helper.ts.

Inside frontend/server/k8s-helper.ts, the functions invoke k8sV1Client.readNamespacedPod(podName, podNamespace) or k8sV1Client.listNamespacedEvent(...). When passed a malformed namespace or a non-existent pod name containing an XSS payload, the Kubernetes API server rejects the request and throws an exception. The catch (error) block intercepts this exception, calls parseError(error) to extract the downstream message, and formats a composite string:

const userMessage = \Could not get pod ${podName} in namespace ${podNamespace}: ${message}`;`

This userMessage is returned to the caller in frontend/server/app.ts (or modular route handlers), which executes res.status(500).send(err.message). In the Express framework, passing a String argument to res.send() automatically sets the HTTP response Content-Type header to text/html; charset=utf-8 unless another type was previously set via res.type() or res.set(). Because no output encoding (such as HTML entity encoding) is applied to podName, podNamespace, or message, the browser renders the reflected string as active HTML.

The vulnerability was remediated in commit fedc25e3f7251933d4a37b964bc3e8176beea28e (Pull Request #12295). The patch addresses the flaw across multiple layers: introducing strict allowlist validation for Kubernetes resource identifiers, removing reflected backend error details, and hardening adjacent handlers for artifacts and TensorBoard integration.

1. Resource Name Validation (frontend/server/utils.ts)

The patch introduces a new validation helper function, isAllowedResourceName, which enforces that resource strings strictly match the Kubernetes DNS-1123 label specification (between 1 and 63 characters, consisting solely of lowercase alphanumeric characters or internal hyphens):

// Added in frontend/server/utils.ts
export function isAllowedResourceName(name: string): boolean {
  return name.length > 0 && name.length <= 63 && /^[a-z0-9]([-a-z0-9]*[a-z0-9])?$/.test(name);
}

Because this regular expression forbids <, >, ", ', /, and all uppercase or special characters, any string passing this check cannot break out of text contexts or introduce HTML tags.

2. Securing Error Generation (frontend/server/k8s-helper.ts)

In frontend/server/k8s-helper.ts, the error handling blocks within getPod, getConfigMap, and listPodEvents were modified to validate inputs before reflecting them and to strip raw Kubernetes error details (message and additionalInfo) from client-facing responses:

// Before Patch (Vulnerable)
export async function getPod(
  podName: string,
  podNamespace: string,
): Promise<[V1Pod | undefined, K8sError | undefined]> {
  try {
    const { body } = await k8sV1Client.readNamespacedPod(podName, podNamespace);
    return [body, undefined];
  } catch (error) {
    const { message, additionalInfo } = await parseError(error);
    // FLAW: Unvalidated podName, podNamespace, and message interpolated directly
    const userMessage = `Could not get pod ${podName} in namespace ${podNamespace}: ${message}`;
    return [undefined, { message: userMessage, additionalInfo }];
  }
}
 
// After Patch (Remediated)
export async function getPod(
  podName: string,
  podNamespace: string,
): Promise<[V1Pod | undefined, K8sError | undefined]> {
  try {
    const { body } = await k8sV1Client.readNamespacedPod(podName, podNamespace);
    return [body, undefined];
  } catch (error) {
    let userMessage = `Could not get pod ${podName} in namespace ${podNamespace}`;
    // FIX: Validate both parameters against strict DNS-1123 regex
    if (!isAllowedResourceName(podName) || !isAllowedResourceName(podNamespace)) {
      userMessage = `Invalid resource name`;
    }
    // FIX: Downstream error message and additionalInfo are omitted
    return [undefined, { message: userMessage }];
  }
}

Identical validation logic was applied to listPodEvents(podName, podNamespace) and getConfigMap(configMapName, configMapNamespace) within the same file.

3. Hardening Additional Frontend and Backend Handlers

The commit also audited other request handlers for similar input reflection and verbose error exposure patterns:

// frontend/server/handlers/artifacts.ts
if (!isAllowedResourceName(bucket)) {
  res.status(500).send('Invalid bucket name');
  return;
}
 
// frontend/server/handlers/tensorboard.ts
if (typeof namespace !== 'string' || !isAllowedResourceName(namespace as string)) {
  res.status(400).send('invalid namespace');
  return;
}

Additionally, in the Go backend (backend/src/apiserver/server/pipeline_upload_server.go), detailed internal error strings returned during pipeline creation and upload failures were replaced with static messages (errors.New("Failed to create a pipeline") and errors.New("Failed to create a pipeline version")), while preserving full diagnostic logging server-side via glog.Errorf.

Fix Completeness Assessment

The introduction of isAllowedResourceName effectively blocks HTML/JavaScript injection via podname, podnamespace, configMapName, bucket, and namespace parameters by restricting the character set to [a-z0-9-]. Furthermore, removing ${message} from the error string eliminates the risk of secondary XSS or sensitive information disclosure originating from upstream Kubernetes API server error responses. However, the application still uses res.status(500).send(...) without explicitly setting Content-Type: text/plain or application/json. While the strict character allowlist prevents XSS in the patched routes, setting an explicit text/plain content type alongside X-Content-Type-Options: nosniff would provide stronger defense-in-depth against future regressions.

Exploiting CVE-2026-88986 requires no authentication on the part of the attacker to construct the payload, though user interaction (UI:R) is required. Specifically, a user who satisfies the Kubeflow deployment's authentication and route-access requirements must navigate to an attacker-supplied link.

Attack Prerequisites

1. Network Access & Authentication: The target victim must have active network access to the Kubeflow Pipelines frontend and possess an active authenticated session (if the deployment enforces authentication via an identity-aware proxy such as Istio/OAuth2 Proxy or Dex).
2. Navigation Interaction: Because the vulnerability is triggered via an HTTP GET request to a top-level URL (/pipeline/k8s/pod or /pipeline/k8s/pod/events), standard browser SameSite=Lax cookie policies do not block session cookies when a user clicks a link from an external site, email, or chat client.

Proof-of-Concept Analysis

In the regression unit tests introduced in frontend/server/app.test.ts within commit fedc25e3f7251933d4a37b964bc3e8176beea28e, the following paths demonstrate the attack vector:

GET /pipeline/k8s/pod?podname=test-pod-name&podnamespace=test-namespace%7d%7dt93g1%3Cscript%3Ealert(1)%3C%2fscript%3Ej66h HTTP/1.1
Host: kubeflow.example.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

As well as the events endpoint variant:

GET /pipeline/k8s/pod/events?podname=test-pod-name&podnamespace=test-namespace%7d%7dt93g1%3Cscript%3Ealert(1)%3C%2fscript%3Ej66h HTTP/1.1
Host: kubeflow.example.com

Exploitation Flow

1. The victim clicks the URL containing the URL-encoded <script>alert(1)</script> payload inside the podnamespace (or podname) parameter.
2. The Express server decodes the query parameter into test-namespace}}t93g1<script>alert(1)</script>j66h and queries the Kubernetes API.
3. The Kubernetes API returns an error because the namespace does not exist and violates Kubernetes naming rules.
4. In versions prior to 2.15.0, the server responds with HTTP 500 and an HTML body:

Could not get pod test-pod-name in namespace test-namespace}}t93g1<script>alert(1)</script>j66h: ...

5. The victim's browser parses the <script> tag and executes the JavaScript payload under the Kubeflow frontend's origin. In patched versions (>= 2.15.0), the server detects that podnamespace fails isAllowedResourceName() and returns the static text Invalid resource name.

CVE-2026-88986 is rated as Medium severity with a CVSS v3.1 base score of 6.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).

Security Impact Breakdown

• Arbitrary Frontend Action Execution (Integrity Impact: Low): Because the injected JavaScript executes within the origin of the Kubeflow Pipelines web interface, the script can issue authenticated XMLHttpRequest (XHR) or Fetch requests to any Kubeflow Pipelines API endpoint accessible to the victim. In a machine learning platform context, an attacker can programmatically trigger pipeline runs, modify experiment configurations, upload malicious pipeline definitions (which subsequently execute container workloads on the Kubernetes cluster), or read sensitive pipeline artifacts.
• Data and Session Exposure (Confidentiality Impact: Low): The payload can read any sensitive data accessible via the DOM, localStorage, or sessionStorage, as well as query backend APIs for pipeline parameters, environment variables, or artifact contents. Whether session cookies can be directly exfiltrated via document.cookie depends on whether the deployment's authentication layer sets the HttpOnly attribute on session cookies.
• Scope Change (S:C): While the vulnerability resides in the server-side Node.js response generation logic, the impact manifests within the client's web browser, crossing a security boundary from the web server to the client execution environment.
• Server-Side Isolation (A:N): As noted in the official advisory, the flaw does not directly provide server-side code execution on the kfp-frontend Node.js container or disrupt service availability.

Threat Intelligence Context

As of November 2026, the FIRST Exploit Prediction Scoring System (EPSS) assigns CVE-2026-88986 a score of 0.00276 (0.28% probability of exploitation within 30 days, placing it in the 20.17th percentile). It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no weaponized exploitation in the wild has been reported.

Organizations running Kubeflow Pipelines should apply the official patch or implement compensating controls at the ingress layer.

1. Upgrade to Patched Release

Upgrade Kubeflow Pipelines to version 2.15.0 or later. Version 2.15.0 incorporates commit fedc25e3f7251933d4a37b964bc3e8176beea28e, which enforces strict input validation on podname, podnamespace, configMapName, bucket, and namespace parameters and removes verbose error reflection.

> [!NOTE] > Ensure that both the kfp-frontend container image and the kfp-apiserver image are updated to version 2.15.0 to benefit from both the frontend XSS protections and backend verbose error suppression.

2. Web Application Firewall (WAF) & Ingress Filtering

If an immediate upgrade is not feasible, administrators can block exploitation attempts at the Kubernetes Ingress controller, Envoy/Istio gateway, or external WAF by enforcing parameter validation on /pipeline/k8s/pod and /pipeline/k8s/pod/events:

• Allowlist Enforcement: Restrict the podname and podnamespace query parameters to match the regular expression ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ with a maximum length of 63 characters.
• XSS Meta-Character Filtering: Block HTTP requests to /pipeline/k8s/* containing raw or URL-encoded HTML special characters (<, >, ", ', %3C, %3E, %22, %27).

3. Response Header Hardening

Configure the reverse proxy or ingress gateway fronting kfp-frontend to inject defensive HTTP response headers:

• Content-Security-Policy (CSP): Enforce a strict CSP header such as Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; to prevent the execution of inline <script> tags and event handlers injected via reflected parameters.
• X-Content-Type-Options: Set X-Content-Type-Options: nosniff to prevent browsers from MIME-sniffing responses away from declared content types.
• Cookie Security: Ensure that any authentication proxy (e.g., OAuth2 Proxy, Istio EnvoyFilter) sets the HttpOnly, Secure, and SameSite=Strict (or Lax) attributes on all session cookies.