CVE-2026-110220: High SSRF in Kubeflow Model Registry

CVE-2026-110220 is a High severity (CVSS 7.1) server-side request forgery in Kubeflow Model Registry through 0.3.17. A namespace user can steal the controller's ServiceAccount token. We could not confirm a fixed version, so limit who can create InferenceServices and check the project.

What's affected

The record says Kubeflow Model Registry through 0.3.17 is affected. The record points to the kubeflow/hub repository. The VulnCheck advisory we read does not name a fixed version, so we do not state one. Check the kubeflow/hub releases before you plan an upgrade.

The weakness is CWE-918, server-side request forgery. Per the record, the InferenceService controller reads the annotation modelregistry.kubeflow.org/url from an InferenceService and sends requests to it with its own bearer token. A user who can create an InferenceService in a namespace can point that annotation at a server they run and capture the token.

With that token, the record says an attacker can modify other tenants' InferenceServices cluster-wide. Severity differs by source: the record gives 7.1 (High) and VulnCheck lists 7.1 on a CVSS 4.0 vector, so the two agree.

How to check if you're exposed

Find out whether the controller is deployed and which version it runs.

kubectl get deploy -A | grep -i model-registry

Then check the image tag of the controller in that deployment. If it is 0.3.17 or lower, you are in range.

Next, look for InferenceServices that carry the url annotation, since normal workloads rarely need it.

kubectl get inferenceservice -A -o yaml | grep "modelregistry.kubeflow.org/url"

Review any hit and the URL it points to. Also check the cluster role bound to the controller to see how much a stolen token could change. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.

What to do now

1. Check the kubeflow/hub project for a release that fixes the issue, and plan an upgrade once you have confirmed which version that is.
2. Use admission control, such as a policy engine, to reject or strip the modelregistry.kubeflow.org/url annotation from objects created by tenants.
3. Restrict who can create InferenceServices in shared clusters.
4. Apply egress network policies to namespaces so workloads and controllers can only reach approved destinations.
5. Reduce the controller's ServiceAccount permissions to what it needs, and rotate its token if you find a suspicious annotation.

Why it matters

In multi-tenant clusters, controllers run with more privilege than tenants do. When a controller takes a URL from a tenant controlled object and calls it with its own credentials, the tenant has a way to borrow that privilege. The attacker does not need to break into the controller. The controller delivers its own token.

The usual defenses are to allow only known destinations, to avoid attaching credentials to requests that go to user supplied addresses, and to keep controller tokens narrow. The record does not mark this CVE as known exploited, and none of the pages we read say it is.

Quick check

Sources

• VulnCheck advisory

Last reviewed: 18 October 2026.