MLflow's CVE-2026-64849 vulnerability exposes a critical security flaw due to a missing authentication check on its webhook endpoint. This allows unauthenticated requests to trigger server-side request forgery (SSRF), with a NVD score of 9.3. The flaw enables an attacker to make the MLflow server fetch arbitrary URLs, bypassing common mitigations like allowlists due to redirect and DNS rebinding capabilities. The deep implications stem from MLflow's role as a central hub, storing sensitive credentials for databases, artefact stores, and model registries. An attacker can leverage this SSRF to access cloud metadata endpoints, internal Kubernetes APIs, administrative artefact storage, and pod network ports. Crucially, the attacker only needs a GET request to exfiltrate tokens or signed URLs, not a full shell.A related vulnerability, though not requiring this CVE, involves MLflow's model gateway configuration that stores API keys. If an attacker can write gateway configuration, these provider keys can be exfiltrated without SSRF. Both issues highlight that MLflow both stores secrets and initiates outbound calls on behalf of potentially unauthenticated users. Beyond upgrading to version 3.15.0, organizations must implement robust egress policies to restrict MLflow's outbound network access. Hardening metadata access and regularly rotating service credentials are also crucial steps to mitigate risk. Auditing gateway configurations for suspicious api_key references and api_base values is essential. Finally, MLflow tracking servers, being internal tools, should be placed behind single sign-on solutions and not exposed publicly. The widespread exposure of MLflow instances indicates many teams have overlooked the risk of publicly accessible internal tools holding critical credentials.