CVE-2026-33866

What it actually does

CVE-2026-33866 is an authorization bypass in MLflow affecting versions through 3.10.1. The vulnerable AJAX artifact-download path does not consistently enforce experiment-level access-control checks before returning saved model artifacts. A low-privileged authenticated user can directly call the endpoint with identifiers or paths associated with an experiment they are not permitted to access and receive model artifact content. The impact is limited to confidentiality of model artifacts; the described flaw does not provide code execution, privilege escalation, data modification, or service disruption by itself.

Why it matters to the business

Organizations using MLflow to store or serve machine-learning experiment artifacts may have exposed proprietary models, training outputs, feature-processing logic, serialized objects, model metadata, or embedded secrets contained in artifacts to users who should not have access. This can lead to intellectual-property leakage, privacy or compliance exposure if artifacts contain sensitive data, and loss of competitive advantage. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but MLflow deployments are often centralized and may contain high-value research or production model assets, so exposure should still be treated seriously where multi-user access controls are relied upon.

How an attack unfolds

An attacker first obtains valid low-privileged access to an MLflow server, such as a normal user account with access to at least some experiments. The attacker then discovers or guesses experiment, run, model, artifact, or path identifiers through the UI, API responses, shared links, logs, predictable naming, or prior access. Instead of using the normal UI workflow, the attacker sends crafted HTTP requests directly to the AJAX endpoint used by MLflow to retrieve saved model artifacts. Because the vulnerable code path omits the expected authorization check for the target experiment, MLflow returns artifacts even when the caller is not authorized for that experiment. The attacker can then download model files, serialized objects, configuration files, notebooks, metrics exports, and other artifact contents for offline analysis or theft.

How to fix it

Upgrade MLflow to a version that contains the authorization fix as soon as the project publishes one; the advisory states that MLflow versions through 3.10.1 are affected and no fixed version was provided in the input. Until a fixed release is deployed, reduce exposure by placing MLflow behind a trusted authentication and authorization layer, limiting access to only users who require artifact access, disabling public or broad network access, and enforcing network restrictions such as VPN, private subnets, IP allowlists, or service mesh policies. Review MLflow tracking-server configuration, artifact-store permissions, and reverse-proxy rules to ensure users cannot directly reach vulnerable AJAX artifact routes except through controlled access paths. Where feasible, segregate highly sensitive experiments into separate MLflow instances or backing artifact stores with independent access controls. Rotate secrets that may have been stored in artifacts and remove credentials, tokens, private keys, or sensitive datasets from model artifact bundles.

How to confirm the fix worked

Confirm the running MLflow version on all servers and containers and treat versions through 3.10.1 as affected. After upgrading or applying compensating controls, test with a low-privileged account that lacks access to a known private experiment: direct requests to the artifact-download AJAX endpoint for that experiment should be denied with an authorization error such as HTTP 401 or 403, not return artifact content or download redirects. Validate that reverse proxies and ingress controls block unauthenticated or unauthorized access to MLflow AJAX and artifact routes. Review artifact-store permissions independently to ensure direct object-store access cannot bypass MLflow authorization. Re-run regression tests for experiment isolation and artifact download permissions after any MLflow upgrade, proxy change, or authentication-provider change.

Typical attack path

1. Acquire valid credentials or session access to an MLflow deployment with at least low-privileged permissions.
2. Identify candidate experiment, run, model, or artifact identifiers through legitimate access, predictable IDs, shared URLs, browser history, logs, or API enumeration.
3. Craft direct HTTP requests to the MLflow AJAX artifact-download endpoint rather than accessing artifacts through the normal authorized UI path.
4. Request saved model artifact paths associated with experiments the user should not be able to access.
5. Download returned artifact files and review them for proprietary models, sensitive data, embedded credentials, source code, or operational details.
6. Repeat requests across additional runs, experiments, or model versions to harvest further artifacts.

How to detect it

Review MLflow application logs, reverse-proxy logs, ingress-controller logs, web access logs, identity-provider logs, and artifact-store access logs for evidence of unauthorized artifact downloads. Focus on authenticated users making direct requests to MLflow AJAX or artifact download routes for experiments, runs, or model versions they were not authorized to access. Look for unusual spikes in artifact downloads, repeated requests for many run IDs or artifact paths, access to saved model directories by users outside the owning team, HTTP 200 responses for artifact-download requests without preceding normal UI navigation, and downloads from unusual IP addresses, user agents, times of day, or service accounts. Correlate requested run, experiment, model, and artifact identifiers against MLflow permission records and project ownership. If object storage is used for artifacts, compare MLflow web logs with object-store read events to determine which files were retrieved. Because this vulnerability is an authorization flaw, there may be no malware-like IOC; the strongest evidence is a valid user successfully retrieving artifact paths that should have been denied.

• /ajax-api/2.0/mlflow-artifacts/artifacts
• /ajax-api/2.0/mlflow/artifacts
• /ajax-api/2.0/mlflow/artifacts/list
• /api/2.0/mlflow-artifacts/artifacts
• /get-artifact
• GET /ajax-api/2.0/mlflow-artifacts/artifacts
• GET /api/2.0/mlflow-artifacts/artifacts
• path=artifacts
• path=model
• MLmodel
• conda.yaml
• python_env.yaml
• requirements.txt
• model.pkl
• model.joblib
• model.onnx
• model.pt
• model.pth
• model.ckpt
• saved_model.pb

What your security team should do

• Inventory all MLflow tracking servers, including development, research, staging, and production instances, and identify any running versions through 3.10.1.
• Restrict MLflow network exposure immediately, especially for internet-accessible or broadly reachable internal deployments.
• Apply the vendor fix as soon as a patched MLflow release is available; until then, use compensating controls at the proxy, identity provider, network, and artifact-store layers.
• Search access logs for low-privileged users downloading artifacts from experiments they do not normally access, especially via direct AJAX/API calls rather than interactive UI navigation.
• Review downloaded or exposed artifacts for embedded secrets, credentials, datasets, proprietary model weights, serialized code, or regulated information, and rotate any exposed secrets.
• Harden MLflow artifact-storage backends so object-store permissions are not broader than MLflow application permissions.
• Add automated authorization tests that verify users cannot list or download artifacts from experiments outside their permitted scope.
• Educate MLflow users not to store credentials, access tokens, private keys, or raw sensitive data inside model artifacts.