GHSA-G3QX-FRCG-J979
Vulnerability from github – Published: 2026-11-09 23:25 – Updated: 2026-11-09 23:25Summary
The Kubeflow Pipelines frontend reflected untrusted pod names and namespaces into HTML error responses from the pod-information and pod-events routes. An attacker could craft a link that causes JavaScript to execute in the frontend's origin when a user follows it and reaches an affected error response.
Affected routes include /pipeline/k8s/pod and /pipeline/k8s/pod/events (the deployment's configured base path may differ).
Impact and prerequisites
Successful exploitation requires a victim to open an attacker-supplied link and reach the vulnerable response. JavaScript execution may expose information accessible to the victim's browser or perform actions in the application's origin.
The attacker does not need an account merely to construct and deliver the link. The victim must satisfy the deployment's authentication and route-access requirements. Cookie theft depends on cookie attributes and deployment protections; it is not guaranteed. The submitted evidence does not establish an availability impact or server-side code execution.
Technical details
The pod handlers pass podname and podnamespace query values to getPod and listPodEvents in frontend/server/k8s-helper.ts. Before remediation, failure messages incorporated those values, along with backend error details, and were returned as HTML-capable string responses.
Kubernetes rejecting an invalid resource name did not prevent the issue: the rejected name could still be included in the frontend's error response.
PR #12295 changed the error construction to validate pod names and namespaces with isAllowedResourceName. Invalid values produce a constant error message instead of reflecting the supplied value, and backend error details are no longer included in these responses. The change includes invalid-resource-name tests.
Affected versions and remediation
Affected product: the Kubeflow Pipelines frontend server, identified as ghcr.io/kubeflow/kfp-frontend. Historical releases may use earlier image registry names.
Upgrade to KFP 2.15.0 or later.
The fix merged on October 10, 2025, in commit fedc25e3f7251933d4a37b964bc3e8176beea28e. It is first present in the 2.15.0 release, published November 25, 2025.
The affected range is recorded as < 2.15.0. The original introduction version and separate maintenance-branch backports have not been established. These are KFP component versions, not Kubeflow platform or Python SDK versions.
Distinction from existing artifact XSS
CVE-2023-6571, tracked in the repository as GHSA-j9xw-rrjg-2p9r, documents reflection of the artifact source parameter in an unknown-storage-source error.
This report concerns different handlers and error construction: pod information and pod events. The artifact-source fix in PR #9844, released in 2.0.2, did not repair these pod responses. They required the later change in #12295.
This independently fixable pod-route defect is tracked as CVE-2026-88986. It does not broaden CVE-2023-6571 or absorb artifact-content rendering and other XSS reports.
Attribution
@pwny0 submitted this report on September 23, 2023, and retains the reporter credit.
@JerT33 authored the remediation in PR #12295. Fix attribution is separate from vulnerability-report attribution.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kubeflow/pipelines"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20251010122814-fedc25e3f725"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-88986"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-09T23:25:58Z",
"nvd_published_at": "2026-11-05T22:18:54Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe Kubeflow Pipelines frontend reflected untrusted pod names and namespaces into HTML error responses from the pod-information and pod-events routes. An attacker could craft a link that causes JavaScript to execute in the frontend\u0027s origin when a user follows it and reaches an affected error response.\n\nAffected routes include `/pipeline/k8s/pod` and `/pipeline/k8s/pod/events` (the deployment\u0027s configured base path may differ).\n\n## Impact and prerequisites\n\nSuccessful exploitation requires a victim to open an attacker-supplied link and reach the vulnerable response. JavaScript execution may expose information accessible to the victim\u0027s browser or perform actions in the application\u0027s origin.\n\nThe attacker does not need an account merely to construct and deliver the link. The victim must satisfy the deployment\u0027s authentication and route-access requirements. Cookie theft depends on cookie attributes and deployment protections; it is not guaranteed. The submitted evidence does not establish an availability impact or server-side code execution.\n\n## Technical details\n\nThe pod handlers pass `podname` and `podnamespace` query values to `getPod` and `listPodEvents` in `frontend/server/k8s-helper.ts`. Before remediation, failure messages incorporated those values, along with backend error details, and were returned as HTML-capable string responses.\n\nKubernetes rejecting an invalid resource name did not prevent the issue: the rejected name could still be included in the frontend\u0027s error response.\n\n[PR #12295](https://github.com/kubeflow/pipelines/pull/12295) changed the error construction to validate pod names and namespaces with `isAllowedResourceName`. Invalid values produce a constant error message instead of reflecting the supplied value, and backend error details are no longer included in these responses. The change includes invalid-resource-name tests.\n\n## Affected versions and remediation\n\nAffected product: the Kubeflow Pipelines frontend server, identified as `ghcr.io/kubeflow/kfp-frontend`. Historical releases may use earlier image registry names.\n\nUpgrade to **KFP 2.15.0 or later**.\n\nThe fix merged on October 10, 2025, in commit [fedc25e3f7251933d4a37b964bc3e8176beea28e](https://github.com/kubeflow/pipelines/commit/fedc25e3f7251933d4a37b964bc3e8176beea28e). It is first present in the **2.15.0** release, published November 25, 2025.\n\nThe affected range is recorded as `\u003c 2.15.0`. The original introduction version and separate maintenance-branch backports have not been established. These are KFP component versions, not Kubeflow platform or Python SDK versions.\n\n## Distinction from existing artifact XSS\n\n[CVE-2023-6571](https://github.com/advisories/GHSA-7rvc-xw75-43jf), tracked in the repository as [GHSA-j9xw-rrjg-2p9r](https://github.com/kubeflow/pipelines/security/advisories/GHSA-j9xw-rrjg-2p9r), documents reflection of the artifact `source` parameter in an unknown-storage-source error.\n\nThis report concerns different handlers and error construction: pod information and pod events. The artifact-source fix in [PR #9844](https://github.com/kubeflow/pipelines/pull/9844), released in 2.0.2, did not repair these pod responses. They required the later change in #12295.\n\nThis independently fixable pod-route defect is tracked as CVE-2026-88986. It does not broaden CVE-2023-6571 or absorb artifact-content rendering and other XSS reports.\n\n## Attribution\n\n**@pwny0** submitted this report on September 23, 2023, and retains the reporter credit.\n\n**@JerT33** authored the remediation in PR #12295. Fix attribution is separate from vulnerability-report attribution.",
"id": "GHSA-g3qx-frcg-j979",
"modified": "2026-11-09T23:25:58Z",
"published": "2026-11-09T23:25:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubeflow/pipelines/security/advisories/GHSA-g3qx-frcg-j979"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88986"
},
{
"type": "WEB",
"url": "https://github.com/kubeflow/pipelines/pull/12295"
},
{
"type": "WEB",
"url": "https://github.com/kubeflow/pipelines/commit/fedc25e3f7251933d4a37b964bc3e8176beea28e"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubeflow/pipelines"
},
{
"type": "WEB",
"url": "https://github.com/kubeflow/pipelines/releases/tag/2.15.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Kubeflow Pipelines: Reflected XSS in the frontend pod information and events error responses"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.