🔥 CyberForge CVE of the Day #092 🚨 CVE-2026-118759 — Kubeflow Pipelines: a run-log request must carry permission, not just identifiers A run ID tells a service which workload you mean. It does not establish that you may read that workload's output. Kubeflow's advisory describes a missing authorisation check in the Pipelines API server that can expose live or archived execution logs through the server's own permissions. ⚠️ Prioritise affected, reachable API servers; upgrade to 2.18.0 and verify run-log permissions, live-pod binding and archived-log access. Treat possible secrets in earlier logs as a separate response question. 🎯 The quick hit: What is happening? A caller who reaches the backend and knows a victim run ID plus a suitable pod/node identifier can obtain logs without the missing per-run check. Both live and archived paths are in scope. For live logs, the vulnerable implementation also fails to verify that the selected pod belongs to the requested run. Logs may contain workload data or credentials; code execution is not established. Who needs to check? Owners of Kubeflow Pipelines API servers through 2.17.3. The CNA expresses the range as below 2.18.0; the first affected release is unresolved. Inventory the server deployment and every serving replica, plus its ingress and internal access paths. An installed Python SDK version is insufficient server evidence. Why does it matter? Authentication at a proxy and authorisation to a particular run are different decisions. A gate can reduce who reaches the handler while leaving an authenticated caller able to request another user's logs. Known identifiers are prerequisites, not proof of ownership; unauthenticated identifier enumeration is not assumed. Start with: the platform owner confirms running API-server images/digests and access controls, then plans the published 2.18.0 upgrade. Review custom roles for the dedicated `readLog` verb on `runs` in `http://pipelines.kubeflow.org`. Restrict backend log-endpoint access while the upgrade is pending, following maintainer guidance. Follow this trail: ingress/application caller context → requested run and namespace → live pod or archived log object → read result and returned bytes. Preserve Kubernetes audit context separately: the Kubernetes caller may be the API server's service account, not the original person. Escalate when: evidence supports an unauthorised read, a run/pod ownership mismatch with returned log content, or subsequent use of a credential plausibly exposed in those logs. A vulnerable version alone establishes exposure, not an incident. Be careful with: HTTP 200, missing audit data, mutable image tags and an upgrade that omits custom permissions. None independently settles access, disclosure or incident closure. 🔑 Key details: ⭐ Severity: High, GitHub_M CNA / Kubeflow maintainer advisory. 📊 CVSS v3.1: 7.5. Exact vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`. 🧠 Weaknesses: CWE-200, Exposure of Sensitive Information to an Unauthorized Actor; CWE-862, Missing Authorization. No valid CVSS v4.0 score was available in the reviewed records; an empty/default score field is not a zero-severity assessment. 🎯 Component: Kubeflow Pipelines API server. Maintainer package: `http://ghcr.io/kubeflow/kfp-api-server`. 🌐 Entry point: the run-log HTTP handler, `GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log`. This route is a scope/evidence lead, not a unique malicious IOC or an instruction to request someone else's logs. 🔓 Prerequisites: backend reachability and necessary victim run/pod or node identifiers. The handler does not authenticate by itself. PR:N describes access without an independent authentication gate; deployments with such a gate have more restricted exposure. No victim interaction is required. Do not invent public Internet exposure or anonymous enumeration. ⚔️ Capability: unauthorised live or archived log disclosure using server authority. The extra live path can reach the `main` container logs of an unrelated pod in the selected run's namespace, subject to the server's pod-log permissions. This is not a universal cluster-wide read or an established write/availability primitive. 🛡️ Fix: API server 2.18.0; PR #13684 / commit `be4723e33727c6dad71a95cba61e8f61562ab20f`. Updating a client alone does not install this server correction. 📚 NVD: Awaiting Analysis, with a Secondary `security-advisories@github.com` v3.1 score. That is not an independent NIST rating. 🧭 CISA KEV: no exact ID in the equal official direct/mirror catalogue 2026.10.30, 1,766 entries, released 30th October at 17:02:45.3665Z. Non-listing does not prove absence of exploitation. 📈 FIRST EPSS: probability 0.336%; percentile 27.013%; model date 2026-10-30. Probability and relative rank are different measurements. Neither estimates whether your installation is already compromised. 🧾 CISA SSVC: CISA Coordinator v2.0.3, timestamp 2026-10-30T15:47:06.206005Z: Exploitation none, Automatable yes, Technical Impact partial. This dated assessment is separate from provider update times and local incident evidence. 🔬 Public testing: the maintainer reports focused regressions and a separately reported synthetic two-tenant reproduction. No active campaign was independently verified in this bounded review. A synthetic reproduction is not victim telemetry or a deployed-cluster end-to-end test. 🧬 Where the trust boundary broke: The backend resolves the requested run's namespace and reads logs with its own authority. Before the fix, the handler skipped the caller's per-run authorisation. Both live and archived retrieval are affected. The additional live path accepts a pod name without requiring membership of that run, potentially exposing an unrelated pod's `main` container logs within the selected namespace and server permissions. The patch authorises before retrieval. This direct HTTP route copies headers into incoming gRPC metadata for the configured authenticators. A dedicated `readLog` verb retains a SubjectAccessReview even where shared `get`/`list` reads are auto-approved. Owners must verify their actual trusted proxy/identity path; arbitrary caller-supplied identity is not inherently trustworthy. Live retrieval fetches the pod and requires its `pipeline/runid` label to match the run before streaming. This supplements authorisation; it does not certify archive storage permissions or give archived objects pod-label proof. The handler also defers HTTP 200 until the first stream write, allowing early validation errors to return non-2xx JSON. An older 200 record cannot establish permission, complete content or disclosure; later stream errors still need context. Forge interpretation: caller → run permission → resource membership → server read → returned bytes. Possible logged-secret exposure and actual secret use each require additional evidence. 📦 Versions, packages and the exposure window: Use the maintainer's API-server 2.18.0 direction as the operational fixed floor. The advisory names versions through 2.17.3 as affected; the CNA records `< 2.18.0`. The first affected release and exact historical exposure start remain unknown. GitHub's reviewed global advisory represents the project as the Go package `http://github.com/kubeflow/pipelines`, with a fixed pseudo-version `0.0.0-20260904182349-be4723e33727`; it also lists `1.7.0-alpha.3` separately without a first-patched value. OSV's GHSA and CVE records were available. Their package/Git encodings are useful dependency evidence, but do not replace the maintainer's container/server remediation guidance. A Go SBOM match or SDK upgrade alone does not prove that a serving API-server pod runs the correction. The fix commit is dated 4th September 2026 at 18:23:49Z. Release 2.18.0 is dated 28th October at 01:31:46Z; its tag includes the reviewed handler and role changes. CVE publication on 29th October is a disclosure event, not an attack start time. Commit, release, advisory and local installation times must remain separate. Build an owner-supported window from deployment records, image digests, rollout history, routing changes and log retention. Check all replicas: a new deployment spec can coexist with older pods during rollout. A tag is a label; relate the running image ID to trusted build provenance and applicable backports. The release upgrade guide describes synchronous startup database work and deployment-specific availability considerations. Plan backups, capacity, maintenance and rollback with the platform/database owners. It also identifies retained security limitations outside this CVE. Fixing the run-log flaw does not certify complete tenant isolation across every Kubeflow feature. 🧭 Six SOC checks for the actual evidence trail: C01 — Scope the running server Action / location: use approved API-server inventory, image/digest provenance, rollout history and ingress/network controls. Include every serving replica and internal access path. Signal / correlation: join affected build, serving interval and backend reachability. Keep proxy caller, service caller and Kubernetes service account distinct. Benign causes / limits: mutable tags, stale inventories and partial rollouts can disagree. SDK/package detection is insufficient server evidence; an unverified backport leaves applicability unresolved. Escalate: confirmed affected reachable servers need priority repair. Incident triage requires evidence beyond version presence. C02 — Preserve caller-to-log evidence Action / location: retain approved ingress/application records, Kubernetes audit, archive-access metadata and rollout history. Record UTC bounds, clocks, retention, acquisition and missing sources. Signal / correlation: seek caller, requested run/node, target namespace/pod or archive object, time and result/byte evidence. Confirm local schemas; do not invent universal KFP fields. Benign causes / limits: audit `user.username` may be the server's service account. Link the initiating caller separately. Missing policy, retention or a verified cross-service request ID limits reconstruction. Escalate: preserve expiring records or suspected unauthorised content through the response owner. Do not retrieve unrelated tenant logs to demonstrate the flaw. C03 — Hunt permission and ownership mismatches Action / location: review approved time-bounded backend run-log requests and pod-log audit events. Compare historical caller grants, run ownership and pod membership using authorised metadata. Signal / correlation: unexpected cross-profile reads or an unrelated pod deserve examination; establish whether content returned. Kubernetes `pods` / `log` audit resource/subresource records differ from the KFP HTTP route. Benign causes / limits: support, administrators, automation and shared workflows can explain reads. Deleted/recreated pods and changed roles complicate history. A matching route is not a unique IOC. Escalate: corroborated unauthorised return or ownership mismatch with caller/result evidence. Missing permission history remains a gap. C04 — Join live, archive and identity records Action / location: join request → run → pod/archive object → server-mediated read. Ask the storage owner which actor/object metadata exists and how it links to the original caller. Signal / correlation: retain source IDs and clock uncertainty; audit stages sharing an audit ID are not necessarily separate reads. Distinguish attempt, disclosure and later credential use. Benign causes / limits: HTTP 200 alone is insufficient. Metadata audit records lack bodies; SubjectAccessReview decisions can require richer policy. Long streams may have ResponseStarted; missing stages do not prove no access. Escalate: supported unauthorised disclosure, then separately corroborated downstream secret use. Do not infer exfiltration volume or persistence from a request. C05 — Assess sensitive data carefully Action / location: workload/incident owners establish whether relevant existing logs contained sensitive material in the supported window. Use minimal approved evidence; keep secret values out of tickets and broad searches. Signal / correlation: separate a secret being logged, an unauthorised reader obtaining it, and an identity accepting its later use. Correlate scoped account/system/time evidence. Benign causes / limits: expired test values, redaction and legitimate activity can explain material. Missing downstream logs leaves use unresolved. Patching does not erase history or revoke tokens. Escalate: credible disclosure to the response owner for scoped rotation/revocation, session review and workload recovery. Preserve evidence and track these closures separately. C06 — Verify code, grants and service acceptance Action / location: compare running server provenance and installed roles with 2.18.0. Review custom `readLog` grants on `runs` in `http://pipelines.kubeflow.org`, scoped to intended identity/namespace. This is a verb, not `runs/log`. Signal / correlation: owner-led acceptance covers allowed/denied callers, unrelated live pod rejection, archive access, trusted identity propagation and legitimate custom-role users across every replica. Benign causes / limits: missing custom grants can break legitimate access. `get pods/log` answers a different question; virtual KFP resources can confuse generic probes. Use exact release attributes and avoid broad migration grants. Escalate: unexpected permission success, ownership failure, rollout gaps or authorisation errors. Local Forge checks do not replace operational acceptance. 🧰 Tools and bounded checks: Check A — deployment evidence: on an approved, already collected PodList for the actual API-server pods, jq summarises namespace/name, configured images and reported running image IDs/readiness. Confirm schema, collection time and build provenance; no universal deployment selector is assumed. A tag or ready flag alone does not prove fixed code is serving. Check B — audit evidence: on an already scoped Kubernetes audit JSONL working copy, jq selects Event records for `pods` / `log`, showing audit ID/stage, times, Kubernetes user, verb, namespace/pod and response code. The report example caps output at the first 200 matching records in file order, neither newest-first nor complete. Multiple stages can describe one request. Missing policy, retention or fields means insufficient telemetry. Check C — permissions: the owner compares installed grants with the release's exact group/resource/verb/namespace/name and authenticating identity. KFP virtual resources may be absent from discovery, so generic probes can answer the wrong question. Permission review alone does not establish pod ownership or full API acceptance. Two offline report examples received Bash syntax checks and guarded jq compilation on null input only. No case files, log queries, Kubernetes requests, permission changes or exploit tests were performed. Grammar acceptance does not validate real schemas, permissions, detections or outcomes. 🔎 Indicators and collection limits: No CVE-specific malicious IP, domain, file hash or unique payload signature was verified. The endpoint, run IDs, pod names and `pipeline/runid` label are investigation context, not malicious indicators. No tested SIEM rule is claimed. Keep four dispositions separate: exposure established, suspicious lead, validated unauthorised outcome, and telemetry unavailable/insufficient. Missing data is insufficient telemetry. A quiet query, low model probability or KEV non-match cannot convert it into a clean result. Kubernetes audit policy, proxy retention and archive logging determine what can be reconstructed. Current collection settings cannot recreate missing history. Preserve uncertainty in the handover: which caller, run, pod/object, result and time links are supported, and which remain unproved. No findings ≠ proof of a clean system. 🩹 Repair, response and acceptance: Upgrade the API server to 2.18.0 through an applicable supported deployment plan. Restrict backend log-endpoint reachability until upgraded. An external gate is useful exposure control, but it does not supply the missing per-run authorisation. Do not treat a network restriction as verification of the code fix. Install the accompanying role changes and review custom roles selectively. Bundled viewer/editor roles include `readLog`; older custom roles may need a deliberate scoped addition. Validate trusted identity propagation, expected permitted/denied reads, live pod/run binding and archived-log authorisation. Avoid disabling multi-user controls to resolve an upgrade denial. Record running-build acceptance, access-control acceptance and incident/secret-response closure separately. If logs were disclosed, decide rotation/revocation and downstream review from actual affected material and identity evidence. Patch completion does not prove leaked-secret revocation, deletion of historical copies or absence of earlier misuse. 🧾 Evidence and attribution: Confirmed: GitHub_M CNA identity/score/weaknesses, maintainer access prerequisites and server fixed floor, static patch changes, release source, and dated KEV/EPSS/SSVC signals. GitHub's global advisory is reviewed; its Go mapping differs from the maintainer's server-container representation. Maintainer-reported testing: focused regression coverage for denial, identity propagation, pod/run mismatch, archive retrieval and cancellation. The advisory explicitly says no new deployed-cluster end-to-end test was performed for its assessment. MUTEDCYBERSECURITY S.L. separately reported a synthetic two-tenant reproduction, including the unrelated-pod path. Neither is a report of a real-world campaign. Credit: http://bugbunny.ai / bugbunny-research reported the issue; Nayyar (@naruto-lgtm) authored the fix. The advisory also credits later submissions separately. Forge's SOC correlations and escalation criteria are analyst interpretation, not observed attacker procedures. Local exposure, actual disclosure, secret use, a working public PoC and campaign activity were not independently established here. 🔥 CyberForge verdict: Repair the server and verify the permission chain. This High-severity disclosure flaw is consequential because execution logs can carry sensitive workload output, while server authority can conceal the gap between a caller's identity and the data they receive. 🔗 Kubeflow maintainer advisory: https://github.com/kubeflow/pipelines/security/advisories/GHSA-wg5q-x4j9-qm54 CVE record: https://www.cve.org/CVERecord?id=CVE-2026-118759 NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-118759 🔗 2.18.0 release: https://github.com/kubeflow/pipelines/releases/tag/2.18.0 Fix PR #13684: https://github.com/kubeflow/pipelines/pull/13684 Release RBAC migration: https://github.com/kubeflow/pipelines/blob/2.18.0/docs/operator-guides/rbac-migration-2.18.md 🔗 CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog FIRST EPSS lookup: https://api.first.org/data/v1/epss?cve=CVE-2026-118759 Kubernetes auditing: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit #CyberForge #CVE #Kubeflow #Kubernetes #BlueTeam #SOC #Authorization #CloudSecurity
