Summary
MLflow's AI Gateway proxy accepts an API base URL without validating its scheme, host, or destination IP range, then makes requests to that location on behalf of an authenticated caller. An authenticated user, including a read-only account, may use this behavior to access internal services and potentially retrieve sensitive cloud-instance metadata or credentials.
Affected context
The issue occurs in MLflow deployments that use the AI Gateway's gateway-secret creation and raw proxy functionality. It becomes risky when an authenticated user can create a gateway secret with an attacker-controlled auth_config.api_base, and the proxy then combines that stored destination with a caller-supplied path without applying the platform's existing URL and IP-range validation.
Exploit preconditions
- Attack surface: MLflow AI Gateway secret creation and proxy endpoints
- Required access: Any authenticated MLflow account, including accounts without a dedicated gateway-secret permission
- Trigger point: A proxy request using a gateway secret whose
api_basepoints to an internal or otherwise sensitive destination - Why exploitation is possible: The destination is stored without scheme, host, or IP-range validation, while the existing SSRF protection is not applied to this code path
- Response exposure: The proxy returns the upstream response body to the caller
Why this happens
The vulnerability is caused by trusting a user-controlled upstream base URL without enforcing an allowlist or validating its resolved network destination. The gateway proxy subsequently performs server-side requests to that stored value, creating a direct SSRF condition mapped to CWE-918: Server-Side Request Forgery. The missing permission mapping further broadens the set of authenticated users who may reach the vulnerable functionality.
Potential impact
- An attacker may access internal administrative or service endpoints
- Sensitive application responses may be disclosed through the proxy
- Cloud-instance metadata services could be queried
- Temporary cloud credentials or IAM-related information could be exposed
- Internal network reconnaissance or lateral movement could become easier
- Downstream services may receive unauthorized requests from the MLflow server
General mitigation guidance
Mitigation generally focuses on reducing trust in user-supplied destinations and ensuring every server-side HTTP request passes through a consistent SSRF control.
Common defensive patterns include:
- Allowing only approved schemes, hosts, ports, and destination networks
- Resolving hostnames and validating the resulting IP addresses before connection
- Blocking loopback, link-local, private, reserved, and metadata-service ranges
- Reusing centralized SSRF validation for gateway-secret and proxy requests
- Applying explicit authorization scopes to secret creation and proxy operations
- Restricting read-only users from creating or using externally directed gateway secrets
- Limiting outbound network access from MLflow components with network policy
- Returning minimal, filtered upstream responses rather than arbitrary response bodies
- Protecting cloud metadata services with platform-level controls and least-privilege identities
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis patterns that identify HTTP clients receiving configuration or request-derived URLs
- Code review checks for missing scheme, hostname, port, DNS-resolution, and IP-range validation
- Review of all proxy, webhook, callback, and gateway-secret creation paths for shared SSRF enforcement
- Authorization-policy checks confirming sensitive actions have explicit permission mappings
- Runtime monitoring for MLflow connections to private, loopback, link-local, or metadata-service addresses
- Audit-log correlation between secret creation, proxy requests, and unusual upstream destinations
- Egress policies that prevent application workloads from reaching cloud metadata and restricted internal ranges
Automated security review tools can help identify URL flows and missing authorization checks, but findings should be validated against deployment-specific network controls.
