CVE-2026-110220 in Model Registry
Summary
by MITRE • 10/13/2026
Kubeflow Model Registry through 0.3.17 contains a server-side request forgery vulnerability that allows namespace users to steal the controller ServiceAccount token via the modelregistry.kubeflow.org/url annotation. Attackers can create an InferenceService pointing the annotation at their server, capture the bearer token, and modify other tenants' InferenceServices cluster-wide.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Kubeflow Model Registry versions up to 0.3.17 represents a critical security flaw rooted in improper validation of user-supplied input during resource creation processes. Specifically, this is a Server-Side Request Forgery (SSRF) issue that exploits the handling of the modelregistry.kubeflow.org/url annotation within InferenceService resources. When a namespace user creates an InferenceService object, they can specify arbitrary URLs in this annotation field without sufficient sanitization or restriction to internal domains only. This lack of validation allows attackers to direct the Kubeflow control plane components to make HTTP requests to external servers controlled by the attacker rather than legitimate model serving endpoints.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and lateral movement within a Kubernetes cluster. By crafting an InferenceService with a malicious URL pointing to their own server, an attacker can trigger the Kubeflow controller to initiate a request that includes sensitive authentication credentials attached as headers or cookies. The most critical piece of data exposed in this scenario is the ServiceAccount token associated with the namespace where the attack originates. Once captured by the attacker's server, this bearer token provides authenticated access to the Kubernetes API server for that specific service account. This effectively bypasses initial network boundaries and allows the adversary to interact directly with the cluster control plane using the permissions granted to that compromised identity.
With possession of a valid ServiceAccount token, an attacker can perform actions far beyond simple data exfiltration. They can enumerate resources within the namespace and potentially escalate privileges if the service account has broader roles bound to it. More critically, as noted in the vulnerability description, this access enables the modification of other tenants' InferenceServices on a cluster-wide basis if the compromised token possesses sufficient RBAC permissions. This leads to a complete compromise of multi-tenant isolation guarantees inherent in shared Kubernetes environments. Attackers could inject malicious code into model serving pipelines, disrupt availability by deleting resources, or further pivot through the cluster using the stolen credentials as a foothold for deeper infiltration.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), which covers flaws where an application fetches a remote resource without validating the user-supplied URL. Additionally, it relates to CWE-20 Improper Input Validation and CWE-798 Use of Hard-coded Credentials if the service account tokens are considered static secrets within that context. In terms of MITRE ATT&CK for Kubernetes, this behavior maps to T1534 Internal Spearphishing or more accurately T1608 Install Resilient Web Shell if persistence is established via modified services, but primarily it falls under T1078 Valid Accounts and T1528 Steal Application Access Token. The attack vector leverages the trust relationship between application components and their configured endpoints to extract high-value secrets.
Mitigation strategies must focus on strict input validation and network segmentation for internal service communications. Administrators should upgrade Kubeflow Model Registry to a version where this vulnerability is patched, ensuring that URL annotations are validated against an allowlist of permitted domains or IP ranges before being processed by the controller. Implementing NetworkPolicy resources in Kubernetes can restrict outbound traffic from model registry pods to only known and trusted endpoints, preventing SSRF attempts from reaching external attacker-controlled servers. Furthermore, adopting least-privilege principles for ServiceAccount roles ensures that even if a token is compromised, its ability to modify cluster-wide resources or access sensitive secrets remains limited. Regular auditing of RBAC bindings and monitoring for anomalous outbound HTTP requests from control plane components can also aid in early detection and response to such exploitation attempts.