Summary
MLflow model-version handling can accept a schemeless relative path as an artifact location, allowing a server-local file path to be stored as model metadata. A remote caller may then use the artifact retrieval API to read files accessible to the MLflow server process, with exposure depending on authentication and model-creation permissions.
MLflow model-version handling can accept a schemeless relative path as an artifact location, allowing a server-local file path to be stored as model metadata. A remote caller may then use the artifact retrieval API to read files accessible to the MLflow server process, with exposure depending on authentication and model-creation permissions.
Affected context
The issue affects MLflow deployments in the impacted version range when model versions are created through the server API and their sources are processed by the prompt-specific path handling logic. Risk is higher when the MLflow server can access sensitive local files and exposes artifact retrieval functionality to unauthenticated or broadly authenticated users.
The issue affects MLflow deployments in the impacted version range when model versions are created through the server API and their sources are processed by the prompt-specific path handling logic. Risk is higher when the MLflow server can access sensitive local files and exposes artifact retrieval functionality to unauthenticated or broadly authenticated users.
Exploit preconditions
- Attack surface: MLflow model-version creation and artifact retrieval APIs
- Required access: No privileges on default unauthenticated deployments; authenticated access and permission to create registered models may be required when basic authentication is enabled
- Trigger point: Processing a model version source followed by a request to retrieve its artifact
- Why exploitation is possible: Path validation is applied only when a URL scheme is present, allowing a relative local path to bypass the intended restriction and reference files available to the server process
- Attack surface: MLflow model-version creation and artifact retrieval APIs
- Required access: No privileges on default unauthenticated deployments; authenticated access and permission to create registered models may be required when basic authentication is enabled
- Trigger point: Processing a model version source followed by a request to retrieve its artifact
- Why exploitation is possible: Path validation is applied only when a URL scheme is present, allowing a relative local path to bypass the intended restriction and reference files available to the server process
Why this happens
The underlying flaw is incomplete validation of user-controlled artifact paths. The application treats sources differently based on whether they contain a URL scheme, leaving schemeless relative paths outside the normal path-safety checks. In addition, prompt identification based on tag presence rather than a validated true value can place input on the vulnerable handling path. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, because attacker-influenced path data can escape the intended artifact-location constraints.
The underlying flaw is incomplete validation of user-controlled artifact paths. The application treats sources differently based on whether they contain a URL scheme, leaving schemeless relative paths outside the normal path-safety checks. In addition, prompt identification based on tag presence rather than a validated true value can place input on the vulnerable handling path. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, because attacker-influenced path data can escape the intended artifact-location constraints.
Potential impact
- Sensitive local files may be disclosed through the artifact retrieval endpoint
- Credentials, configuration data, or service tokens may be exposed
- MLflow server confidentiality and tenant isolation could be weakened
- Disclosed files could support follow-on compromise of connected systems
- Sensitive local files may be disclosed through the artifact retrieval endpoint
- Credentials, configuration data, or service tokens may be exposed
- MLflow server confidentiality and tenant isolation could be weakened
- Disclosed files could support follow-on compromise of connected systems
General mitigation guidance
Mitigation generally focuses on enforcing a single, secure artifact-location policy for every source format and reducing trust in client-supplied paths.
Common defensive patterns include:
- Canonicalizing paths before validation and enforcing containment within approved artifact directories
- Rejecting local filesystem paths when only managed artifact references are expected
- Applying equivalent validation to schemeless, relative, absolute, and URL-based sources
- Treating boolean-like metadata as validated values rather than relying on tag presence
- Restricting artifact retrieval and model creation to authorized principals
- Running MLflow with least-privilege filesystem access and isolated service credentials
- Avoiding exposure of sensitive host paths to the MLflow process
Mitigation generally focuses on enforcing a single, secure artifact-location policy for every source format and reducing trust in client-supplied paths.
Common defensive patterns include:
- Canonicalizing paths before validation and enforcing containment within approved artifact directories
- Rejecting local filesystem paths when only managed artifact references are expected
- Applying equivalent validation to schemeless, relative, absolute, and URL-based sources
- Treating boolean-like metadata as validated values rather than relying on tag presence
- Restricting artifact retrieval and model creation to authorized principals
- Running MLflow with least-privilege filesystem access and isolated service credentials
- Avoiding exposure of sensitive host paths to the MLflow process
How teams detect issues like this
Organizations can look for:
- Static analysis findings where user-controlled model sources reach filesystem APIs without canonicalization and containment checks
- Code review signals involving scheme-dependent validation, relative-path acceptance, or metadata checks based only on key presence
- API monitoring for model versions whose sources reference local filesystem locations
- Access logs showing unusual artifact retrieval requests or repeated reads across unrelated paths
- Policy enforcement that limits artifact sources to approved URI schemes and managed storage locations
Automated security scanning and code-review tools can help identify inconsistent path validation and unsafe filesystem access patterns.
Organizations can look for:
- Static analysis findings where user-controlled model sources reach filesystem APIs without canonicalization and containment checks
- Code review signals involving scheme-dependent validation, relative-path acceptance, or metadata checks based only on key presence
- API monitoring for model versions whose sources reference local filesystem locations
- Access logs showing unusual artifact retrieval requests or repeated reads across unrelated paths
- Policy enforcement that limits artifact sources to approved URI schemes and managed storage locations
Automated security scanning and code-review tools can help identify inconsistent path validation and unsafe filesystem access patterns.
