Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
68 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
On MLflow tracking servers running without authentication, which is the default for mlflow server, a remote attacker can read arbitrary files from the server’s filesystem by creating a model version tagged as a prompt whose source is a schemeless local path. The fix for CVE-2026-2614 in 3.10.0 added a prompt-specific branch to the `CreateModelVersion` handler that rejects `file://` URIs and absolute paths but runs path validation only when the source carries a URL scheme. A schemeless value such as `../../etc`, a plain relative name, `.`, a percent-encoded path, or a Windows drive-letter path is therefore stored unchanged as the model version’s artifact location, and the `model-versions/get-artifact endpoint` later serves files from it with the privileges of the server process. The tag check also keyed on the presence of the `mlflow.prompt.is_prompt` tag rather than its value, so a false value still selected the weaker branch. Servers using `--app-name basic-auth` are…
Recommended action: Upgrade to 3.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`mlflow.crewai.autolog()` leaks CrewAI LLM provider API keys into MLflow trace telemetry. When a CrewAI `Agent` is instrumented with MLflow autologging, MLflow serializes the agent's `dict` and converts its fields to strings. The `llm` field contains the CrewAI LLM object, whose string representation includes its `api_key` in plaintext. As a result, an application that calls `mlflow.crewai.autolog()` can unintentionally send its LLM provider API key to the MLflow trace backend or configured OTLP destination. The application does not need to explicitly log the credential or place it in a span attribute. The credential is extracted automatically by MLflow's instrumentation. This was verified on MLflow 3.16.0 with CrewAI 1.15.18 using MLflow's own OTLP exporter. The fake credential appeared in 5 attribute locations across 2 spans. Details The primary issue is in: `mlflow/crewai/autolog.py::_get_agent_attributes()` The function walks the CrewAI…
Recommended action: Upgrade to 3.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MLflow 3.12.0 introduced registration and deserialization support for third-party scorers in OSS MLflow. During scorer deserialization, the server accepts a request-controlled Python module path beneath one of four allowed package prefixes, imports that module, obtains a request-controlled class, and instantiates it synchronously. An HTTP caller can combine this behavior with MLflow's built-in experiment, run, and artifact-upload endpoints: 1. Create an experiment whose local artifact location points to a writable allowed scorer package. 2. Create a run, causing MLflow to allocate ` / /artifacts/`. 3. Upload a Python module into that run artifact directory. 4. Submit a serialized third-party scorer whose module path resolves to the uploaded file. 5. Trigger server-side import and class construction through `/ajax-api/3.0/mlflow/scorer/invoke`. On the default no-auth server using the official MLflow v3.14.0 image, this produces unauthenticated arbitrary Python code…
Recommended action: Upgrade to 3.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MLflow's tracking server exposes `POST /ajax-api/3.0/mlflow/scorer/invoke` with no authentication, and the handler reflectively instantiates an attacker-named class from attacker-supplied JSON with unconstrained constructor kwargs. With the optional `trulens` + `trulens-providers-litellm` packages installed, an unauthenticated attacker can force the server to make an outbound HTTP request to an arbitrary host of their choosing, carrying attacker-controlled headers (SSRF). Details `Scorer.model_validate_json()` reflects a class name from a JSON payload behind an import-path allowlist that never constrains the reflected attribute or its kwargs, in `mlflow/genai/scorers/base.py:549-604`: ```python data = serialized.third_party_scorer_data attacker JSON module_path = data.get("module") or "" class_name = data.get("class") if not any(module_path == m or module_path.startswith(m + ".") for m in THIRD_PARTY_SCORER_ALLOWED_MODULES): raise…
Recommended action: Upgrade to 3.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MLflow introduced MLFLOWALLOWPICKLEDESERIALIZATION as a security control to prevent unsafe pickle.load execution during model loading, in response to CVE-2024-37052 through CVE-2024-37060. When set to False, operators expect all pickle deserialization to be blocked. The most recent related fix (#21188) patched a bypass in the pyfunc flavor. However, the mlflow.statsmodels flavor completely omits this guard. An attacker who places a crafted MLmodel artifact into any accessible artifact store can trigger arbitrary code execution on any process that calls mlflow.pyfunc.loadmodel() against the malicious model — even when MLFLOWALLOWPICKLEDESERIALIZATION=False. This is a security control bypass. The operator believes pickle RCE is mitigated; the statsmodels flavor silently ignores the control. --- Root Cause mlflow.pyfunc.loadmodel() dispatches to flavor loadpyfunc implementations via: The guarded pattern (from mlflow/sklearn/init.py L526-533, the reference implementation) is:…
Recommended action: Upgrade to 3.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The default MLflow Tracking Server (mlflow server, no authentication, default SQLite backend) exposes the model-registry webhooks API unauthenticated, including a synchronous POST /api/2.0/mlflow/webhooks/{id}/test endpoint that returns the upstream response status and body to the caller. The SSRF guard added in PR #20747 (validatewebhookurl, shipped in 3.10.0) resolves the webhook hostname and rejects non-public IPs, but it is bypassable: delivery follows HTTP redirects (no allowredirects=False) and never pins the validated IP. An attacker hosts a public HTTPS endpoint that passes the guard and returns 302 Location: http://169.254.169.254/... (or http://127.0.0.1:...); MLflow follows it and never re-validates the redirect target. Because /test reflects the response body, this is an unauthenticated full-read SSRF on a default server. Details Three facts combine: 1. Webhook endpoints are unauthenticated on a default server. The only webhook authorization lives in the optional…
Recommended action: Upgrade to 3.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In MLflow versions prior to 3.13.0, when running with authentication enabled, the trace API endpoints lack proper authorization validators. This allows any authenticated user to bypass experiment-level authorization controls on all trace operations, including reading, deleting, and modifying traces on experiments they do not have permission to access. The issue arises from the beforerequest handler, which does not register authorization validators for trace endpoints, resulting in requests proceeding without validation. This vulnerability can expose sensitive data, destroy audit logs, and allow unauthorized modifications.
Recommended action: Upgrade to 3.13.0rc0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw has been found in MLflow up to 3.10.0. This issue affects the function mlflow.data.digestutils of the file mlflow/data/digestutils.py of the component Dataset Digest Computation. This manipulation causes use of weak hash. It is possible to launch the attack on the local host. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through a pull request but has not reacted yet.
Recommended action: Upgrade to 3.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in mlflow/mlflow versions prior to 3.11.0 allows for the resolution of environment variables in AI Gateway secrets, which can be exploited to exfiltrate sensitive server-side environment credentials to an attacker-controlled endpoint. This issue arises because the apikey field in gateway secrets can accept $ENVVAR references, which are resolved against the MLflow server's environment during runtime. The resolved secrets are then sent in provider authentication headers to the configured upstream apibase. This vulnerability can be exploited by low-privileged authenticated users in basic-auth deployments or by unauthenticated users in default deployments without basic-auth. The impact includes potential leakage of sensitive credentials such as cloud artifact credentials (AWSACCESSKEYID, AWSSECRETACCESSKEY), which could lead to artifact poisoning and cross-boundary code execution in downstream environments. The issue is fixed in version 3.11.0.
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MLflow 3.9.0 with basic-auth (--app-name basic-auth) fails to enforce authorization checks for multiple Gateway API 'list' endpoints. Specifically, the BEFOREREQUESTHANDLERS dictionary in mlflow/server/auth/init.py does not include entries for ListGatewaySecretInfos, ListGatewayEndpoints, and ListGatewayModelDefinitions. This allows any authenticated user, regardless of their assigned permissions, to enumerate all gateway secrets, endpoints, and model definitions. This vulnerability exposes sensitive information, such as API keys, endpoint configurations, and proprietary model definitions, to unauthorized users.
Recommended action: Upgrade to 3.11.0rc0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in MLflow versions <=3.10.1.dev0 allows unauthorized access to multipart upload (MPU) endpoints when the --serve-artifacts mode is enabled. The authorization logic does not enforce resource-level permission checks for /mlflow-artifacts/mpu/ endpoints, enabling attackers to overwrite artifacts belonging to other users. This can lead to unauthorized cross-user writes, model supply chain poisoning, and arbitrary code execution when compromised models are loaded. The issue is resolved in version 3.10.0.
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In mlflow/mlflow versions up to 3.9.0, the SearchModelVersions REST API endpoint and the mlflowSearchModelVersions GraphQL query lack proper per-model authorization checks when basic authentication is enabled. This allows any authenticated user to enumerate all model versions across all registered models, regardless of their permission level. The issue arises due to the absence of SearchModelVersions in the BEFOREREQUESTVALIDATORS and AFTERREQUESTHANDLERS for the REST API, and its omission from GraphQLAuthorizationMiddleware.PROTECTEDFIELDS for GraphQL. This vulnerability can expose sensitive information such as model names, version descriptions, source URIs, tags, and other metadata, potentially revealing proprietary or confidential details in multi-tenant environments. The issue is resolved in version 3.10.0.
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In MLflow version 3.9.0, the MLflow Assistant feature introduced improper origin validation in its /ajax-api endpoints. This vulnerability allows a remote attacker to exploit cross-origin requests from a malicious webpage to interact with the MLflow Assistant running on a victim's local machine. By bypassing the loopback-only restriction, the attacker can modify the Assistant's configuration to enable full access, which in turn allows the execution of arbitrary commands via the Claude Code sub-agent. This issue is resolved in version 3.10.0.
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In mlflow/mlflow versions prior to 3.11.0, the getorcreatenfstmpdir() function in mlflow/utils/fileutils.py creates temporary directories with world-writable permissions (0o777), and the createmodeldownloadingtmpdir() function in mlflow/pyfunc/init.py creates directories with group-writable permissions (0o770). These insecure permissions allow local attackers to tamper with model artifacts, such as cloudpickle-serialized Python objects, and achieve arbitrary code execution when the tampered artifacts are deserialized via cloudpickle.load(). This vulnerability is particularly critical in environments with shared NFS mounts, such as Databricks, where NFS is enabled by default. The issue is a continuation of the vulnerability class addressed in CVE-2025-10279, which was only partially fixed.
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in mlflow/mlflow versions 3.9.0 and earlier allows unauthenticated access to certain FastAPI routes when the server is started with authentication enabled (--app-name basic-auth) and served via uvicorn (ASGI). The FastAPI permission middleware only enforces authentication on /gateway/ routes, leaving other routes such as the Job API (/ajax-api/3.0/jobs/) and the OpenTelemetry trace ingestion API (/v1/traces) unprotected. This allows unauthenticated remote attackers to submit jobs, read job results, cancel running jobs, and inject arbitrary trace data into experiments. The issue arises from an architectural mismatch between Flask and FastAPI authentication mechanisms, where the findfastapivalidator() function fails to handle non-/gateway/ paths, resulting in a complete authentication bypass. This vulnerability is fixed in version 3.10.0.
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in the createmodelversion() handler of mlflow/server/handlers.py in mlflow/mlflow versions 3.9.0 and earlier allows an unauthenticated remote attacker to read arbitrary files from the server's filesystem. The issue arises when a CreateModelVersion request includes the tag mlflow.prompt.isprompt, which bypasses source path validation. This enables an attacker to store an arbitrary local filesystem path as the model version source. The getmodelversionartifacthandler() function later uses this source to serve files without verifying the model version's prompt status, leading to a complete confidentiality compromise. This issue is fixed in version 3.10.0.
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Request Forgery (SSRF) vulnerability exists in MLflow versions prior to 3.9.0. The createwebhook() function in mlflow/server/handlers.py accepts a user-controlled url parameter without validation, and the sendwebhookrequest() function in mlflow/webhooks/delivery.py sends HTTP POST requests to this attacker-controlled URL. This allows an authenticated attacker to force the MLflow backend to send HTTP requests to internal services, cloud metadata endpoints, or arbitrary external servers. The lack of input sanitization, URL scheme filtering, or allowlist validation on the webhook URL enables exploitation, potentially leading to cloud credential theft, internal network access, and data exfiltration.
Recommended action: Upgrade to 3.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MLflow is vulnerable to Stored Cross-Site Scripting (XSS) caused by unsafe parsing of YAML-based MLmodel artifacts in its web interface. An authenticated attacker can upload a malicious MLmodel file containing a payload that executes when another user views the artifact in the UI. This allows actions such as session hijacking or performing operations on behalf of the victim. This issue affects MLflow version through 3.10.1
Recommended action: Upgrade to 3.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MLflow is vulnerable to an authorization bypass affecting the AJAX endpoint used to download saved model artifacts. Due to missing access‑control validation, a user without permissions to a given experiment can directly query this endpoint and retrieve model artifacts they are not authorized to access. This issue affects MLflow version through 3.10.1
Recommended action: Upgrade to 3.11.0rc0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A command injection vulnerability exists in Mlflow when serving a model with enablemlserver=True. The modeluri is embedded directly into a shell command executed via bash -c without proper sanitization. If the modeluri contains shell metacharacters, such as $() or backticks, it allows for command substitution and execution of attacker-controlled commands. This vulnerability affects the latest version of mlflow/mlflow and can lead to privilege escalation if a higher-privileged service serves models from a directory writable by lower-privileged users.
Recommended action: Upgrade to 3.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A command injection vulnerability exists in MLflow's model serving container initialization code, specifically in the installmodeldependenciestoenv() function. When deploying a model with envmanager=LOCAL, MLflow reads dependency specifications from the model artifact's pythonenv.yaml file and directly interpolates them into a shell command without sanitization. This allows an attacker to supply a malicious model artifact and achieve arbitrary command execution on systems that deploy the model. The vulnerability affects versions 3.8.0 and is fixed in version 3.8.1.
Recommended action: Upgrade to 3.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability exists in the extractarchivetodir function within the mlflow/pyfunc/dbconnectartifactcache.py file of the mlflow/mlflow repository. This vulnerability, present in versions before v3.7.0, arises due to the lack of validation of tar member paths during extraction. An attacker with control over the tar.gz file can exploit this issue to overwrite arbitrary files or gain elevated privileges, potentially escaping the sandbox directory in multi-tenant or shared cluster environments.
Recommended action: Upgrade to 3.9.0rc0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in MLflow's pyfunc extraction process allows for arbitrary file writes due to improper handling of tar archive entries. Specifically, the use of tarfile.extractall without path validation enables crafted tar.gz files containing .. or absolute paths to escape the intended extraction directory. This issue affects the latest version of MLflow and poses a high/critical risk in scenarios involving multi-tenant environments or ingestion of untrusted artifacts, as it can lead to arbitrary file overwrites and potential remote code execution.
Recommended action: Upgrade to 3.9.0rc0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A command injection vulnerability exists in mlflow/mlflow versions before v3.7.0, specifically in the mlflow/sagemaker/init.py file at lines 161-167. The vulnerability arises from the direct interpolation of user-supplied container image names into shell commands without proper sanitization, which are then executed using os.system(). This allows attackers to execute arbitrary commands by supplying malicious input through the --container parameter of the CLI. The issue affects environments where MLflow is used, including development setups, CI/CD pipelines, and cloud deployments.
Recommended action: Upgrade to 3.8.0rc0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MLflow Tracking Server Artifact Handler Directory Traversal Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of MLflow Tracking Server. Authentication is not required to exploit this vulnerability. The specific flaw exists within the handling of artifact file paths. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to execute code in the context of the service account.
Recommended action: Upgrade to 3.8.0rc0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.