CVE-2025-15381

What it actually does

CVE-2025-15381 is an authorization bypass in MLflow deployments running the basic-auth application mode. Although basic authentication requires a user to log in, the tracing and assessment APIs do not consistently enforce experiment-level permission validators. As a result, an authenticated low-privilege user, including a user with NO_PERMISSIONS on an experiment, can read trace metadata they should not be able to access and can create or modify trace assessments without proper authorization. The primary impact is unauthorized disclosure of model/application trace data and unauthorized integrity changes to assessment records; availability is not directly affected.

Why it matters to the business

Organizations using MLflow with `mlflow server --app-name=basic-auth` may unintentionally expose sensitive observability data, prompt/response traces, experiment metadata, model evaluation context, or workflow details to users who should not have access. Unauthorized assessments can also pollute evaluation results, governance evidence, quality metrics, or human-feedback workflows, potentially undermining trust in model monitoring and review processes. The CVSS score is high enough to warrant timely remediation, but the currently low EPSS score, absence from CISA KEV, and no known mature public exploit indicate this is more likely to be abused by authenticated insiders or compromised low-privilege accounts than by broad opportunistic internet scanning.

How an attack unfolds

An attacker first obtains valid MLflow credentials for any account, including an account with little or no permission to a target experiment. The attacker identifies that the MLflow deployment is running the `basic-auth` app and then sends authenticated requests directly to tracing or assessment endpoints rather than relying on the normal UI permission flow. Because those endpoints do not enforce the same permission validators as protected experiment resources, the server processes the requests even when the user lacks experiment access. The attacker can enumerate or retrieve trace information and submit assessments tied to traces they should not control, resulting in confidentiality loss and integrity manipulation of evaluation or tracing data.

How to fix it

Upgrade MLflow to a version that includes authorization validation for tracing and assessment endpoints once a fixed release is available from the MLflow project. No fixed version was provided in the input, so track the upstream MLflow security advisory and release notes and apply the first patched release promptly. As compensating controls, avoid exposing MLflow basic-auth deployments broadly, restrict network access to trusted users and administrative networks, place MLflow behind an access proxy that enforces authorization consistently, disable or limit tracing/assessment features where feasible, review user permissions, remove stale accounts, and avoid granting access to shared low-privilege accounts. If basic-auth is not required, consider switching to a deployment pattern with stronger external identity, authorization, and network controls.

How to confirm the fix worked

Confirm whether any MLflow server is launched with `mlflow server --app-name=basic-auth` or equivalent configuration enabling the basic-auth app. Validate exposure by testing with a deliberately low-privilege authenticated account that has no permission on a target experiment and confirming that tracing and assessment endpoints return authorization failures rather than trace data or successful assessment creation. After upgrading or applying compensating controls, repeat the same negative authorization tests and verify HTTP 401/403 responses or equivalent denial behavior. Review package inventory, container images, dependency lockfiles, and running service command lines to confirm all MLflow instances are updated or protected.

Typical attack path

1. Obtain or compromise any valid MLflow user account.
2. Confirm the MLflow server is using the basic-auth application mode.
3. Identify experiments, runs, traces, or trace identifiers through accessible metadata, guessed identifiers, shared links, logs, or prior knowledge.
4. Send authenticated HTTP requests directly to MLflow tracing endpoints to retrieve trace metadata despite lacking experiment permissions.
5. Send authenticated HTTP POST/PUT requests to assessment-related endpoints to create unauthorized assessments for traces.
6. Use the exposed trace data for reconnaissance or sensitive-data collection and use unauthorized assessments to manipulate evaluation, quality, or governance outputs.

How to detect it

Investigate MLflow application logs, reverse-proxy access logs, API gateway logs, authentication logs, and web server logs for authenticated low-privilege users making requests to trace or assessment endpoints associated with experiments they do not have permission to access. Focus on HTTP 200/201 responses from tracing or assessment APIs where the same user would receive denied access for normal experiment or run operations. Look for unusual enumeration patterns, such as one user requesting many trace IDs, repeated calls across many experiments, or assessment creation events by accounts that should not review or score traces. If MLflow is behind a proxy, correlate source IP, username, session identifier, request path, method, status code, and response size. Review assessment records for unexpected authors, timestamps outside normal workflows, duplicate or bulk-created assessments, and assessments from accounts with NO_PERMISSIONS or no business role in the affected experiment. Because no public exploit maturity or KEV exploitation is reported, detection should emphasize insider misuse, compromised valid accounts, and anomalous authenticated API behavior rather than unauthenticated scanning.

• mlflow server --app-name=basic-auth
• --app-name=basic-auth
• /api/2.0/mlflow/traces
• /ajax-api/2.0/mlflow/traces
• /api/2.0/mlflow/assessments
• /ajax-api/2.0/mlflow/assessments
• GET /api/2.0/mlflow/traces
• GET /ajax-api/2.0/mlflow/traces
• POST /api/2.0/mlflow/assessments
• POST /ajax-api/2.0/mlflow/assessments
• NO_PERMISSIONS

What your security team should do

• Inventory all MLflow deployments and prioritize any internet-facing or broadly reachable servers running `mlflow server --app-name=basic-auth`.
• Restrict network access to MLflow immediately using VPN, private networking, firewall rules, reverse-proxy allowlists, or identity-aware access controls.
• Monitor upstream MLflow advisories and upgrade to the first release that fixes authorization checks for tracing and assessment endpoints.
• Audit MLflow users and remove unnecessary accounts, shared credentials, and users with no current business need.
• Perform negative authorization testing with low-privilege users against tracing and assessment APIs before and after remediation.
• Review trace and assessment activity logs for low-privilege accounts accessing experiments they should not be able to view or modifying assessments unexpectedly.
• Treat suspicious unauthorized trace access as potential sensitive data exposure, especially where traces may contain prompts, responses, tokens, customer data, model inputs, or evaluation notes.