Kubeflow Model Registry CVE-2026-110220

Requires an authenticated tenant with permission to create InferenceService resources in a namespace of a multi-tenant Kubeflow Model Registry deployment (≤0.3.17), and an attacker-controlled HTTP endpoint to receive the forwarded token. The trigger is specifically the modelregistry.kubeflow.org/url annotation, which the InferenceService controller follows and to which it attaches its ServiceAccount bearer token - this is default controller behavior, so no special non-default configuration is needed. Limiting factors: the attacker must already hold valid namespace/tenant credentials and InferenceService create rights (PR:L), and must host a reachable collection server; there is no user-interaction requirement, so exploitation is otherwise straightforward for any insider or compromised tenant.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N, base 7.1) frames this as a network-reachable, low-complexity attack that requires low privileges (PR:L) - i.e. an already-authenticated namespace tenant - with no user interaction, yielding low confidentiality (VC:L, the leaked bearer token) but HIGH integrity impact (VI:H, the ability to modify other tenants' InferenceServices cluster-wide). The integrity impact is the real story: this is a multi-tenant isolation break, not merely information disclosure. However, several escalation signals are MISSING: no EPSS score was provided, there is no CISA KEV listing (not actively exploited per available data), no SSVC decision block was supplied, and no confirmed public exploit code was identified (a detailed VulnCheck advisory and a hackmd technical writeup exist, but these document the technique rather than confirm weaponized PoC). Net assessment: a genuine, high-value finding for any organization running multi-tenant Kubeflow Model Registry, because PR:L is a low bar inside a shared cluster and the payoff is cluster-wide tenant compromise - but it is gated behind having authenticated tenant access, and the affected product has a relatively narrow deployment footprint, so this is a targeted-risk issue rather than a mass-exploitation threat. Note the CVSS 4.0 subsequent-system metrics are all N despite the clearly cross-tenant/cross-authorization-boundary impact, which arguably understates the scope dimension - verify against vendor advisory.

A legitimate but malicious (or compromised) tenant with permission to create InferenceService objects in their namespace sets the modelregistry.kubeflow.org/url annotation to point at an attacker-controlled HTTP server. When the Kubeflow InferenceService controller processes the annotation, it forwards its own ServiceAccount bearer token to that server, letting the attacker capture it and then use the controller's cluster-wide privileges to read and modify other tenants' InferenceServices. No weaponized public exploit is confirmed, but VulnCheck and a public hackmd writeup describe the technique in detail.