Unauthenticated SSRF in MLflow's webhook endpoint exposes internal networks behind model registries

The bug

According to a write-up published on dev.to, CVE-2026-64849 is a missing authentication check on MLflow's webhook endpoint. A request that should have required an authenticated session was instead accepted anonymously, and the MLflow server then fetched whatever URL the caller had supplied. That combination — no credentials plus a server-initiated fetch — is classic server-side request forgery. The issue is tracked as GitHub advisory GHSA-7gwp-5pfp-969j, the vulnerable window closes with release 3.15.0, and NVD scores it 9.3, which the dev.to author considers appropriate for an unauthenticated SSRF on a platform that holds model artefacts.

Two aspects of the fix explain why an allowlist alone was never going to work. The first is redirects: the initial request can name a host an operator trusts, and the response can then bounce the fetch somewhere else, so validation that inspects only the first hop proves nothing. The second is DNS rebinding, where a hostname resolves to a public address during the check and to an internal one when the fetch actually happens. Both are well-understood techniques, and both pushed the remediation into the request handler itself rather than into a configuration option.

What the server can reach

The damage is bounded not by the webhook but by the MLflow process's outbound network access. As the dev.to analysis points out, a typical deployment carries database credentials for the backend store, credentials for the artefact store, often a registry token, and — under Kubernetes — a mounted service account token at its default path. A forged request from that process can therefore touch:

• the cloud instance metadata endpoint, wherever metadata access has not been hardened;
• internal Kubernetes API addresses, where the mounted service account token becomes a prize;
• artefact storage administrative endpoints that trust the request's source;
• metrics and admin ports bound to the pod network, which were never meant to be externally reachable.

No payload or exploit chain is needed. A plain GET can return a signed URL or short-lived token in the response body, and that body flows straight back through the webhook call the attacker initiated. The dev.to author stresses that defenders tend to underestimate this: the attacker needs a single successful response, not code execution on the box.

A neighbouring problem that needs no CVE

The same write-up describes a related exposure that does not depend on this vulnerability at all. MLflow's model gateways call third-party AI providers, and their configuration carries API keys. Earlier releases in the same line shipped fixes for behaviour where an api_key field could hold an environment-variable reference, be resolved server-side, and then have the resolved value transmitted to whatever api_base the configuration named. Anyone able to write gateway configuration — via an exposed tracking server, a shared experiment, or a compromised service account with registry write rights — could exfiltrate provider keys without any SSRF. Read together, the two issues amount to a single property: MLflow both stores secrets and makes outbound calls on behalf of anyone who can reach it.

What operators should do

The dev.to post recommends upgrading to 3.15.0 and then assuming the bug class will return. Beyond the patch:

• Restrict egress. The server needs its database, artefact store and model providers; it does not need the metadata service. Denying link-local addresses and non-allowlisted private ranges strips most of the value from future SSRFs.
• Harden metadata access, for example by requiring IMDSv2 with a hop limit of one, or disabling the metadata service on the workload's network namespace.
• Rotate credentials. If the tracking server was internet-reachable and unpatched, treat the database password, artefact store keys and registry token as disclosed — application logs offer weak reassurance, because a forged webhook call resembles a legitimate delivery.
• Audit gateway configuration for api_key values referencing environment variables and api_base values pointing somewhere unexpected, then rotate those provider keys.
• Put the tracking server behind single sign-on at a reverse proxy instead of leaving it alongside demo deployments.

The exposed population

Commercial scanning of the CVE began shortly after publication, and broad fingerprinting placed exposed MLflow-related assets in the tens of thousands, according to dev.to. The author cautions that this is an upper bound rather than a census: fingerprints also count development instances, containers left running on laptops and researcher honeypots. The trend, not the precise figure, is the signal.

Why it matters

Model registries stopped being niche tools, and the population of reachable instances has grown faster than the habit of putting them behind a login. For many teams the genuine exposure was never the webhook itself — it was that an internal build tool holding credentials for the entire model pipeline answered on a public address, and nobody had documented that it did. The durable defence here is architectural: control egress, harden metadata access and put authentication in front of internal tooling, because patches address individual bugs while the value of any SSRF scales with everything the server can reach.