CVE-2024-6838

What it actually does

MLflow (described in v2.13.2) does not enforce a maximum length on experiment names during create or rename, nor on the artifact_location parameter at experiment creation. An oversized name made of a large volume of integer characters, or an unbounded artifact_location string, can exhaust UI rendering or request-handling resources so the MLflow UI panel becomes unresponsive. Impact is availability-only (denial of service); the described flaw does not confer code execution, authentication bypass, or data disclosure by itself.

Why it matters to the business

Experiment-tracking dashboards can freeze, interrupting data-science and ML-ops work until the UI or tracking process is restarted and the oversized record is removed. CVSS is moderate (5.3). EPSS is low (~0.65%) and essentially flat over 30 days (0.0064 → 0.0065, +2%), the issue is not in CISA KEV, is not associated with ransomware, and has no known exploit maturity more than a year after publication—so this is a service-availability risk, not an emergency patch event, unless a shared or internet-exposed tracking UI is on a critical path.

How an attack unfolds

An actor who can create or rename experiments on a tracking server—sometimes with little or no privilege if the server is open—submits an experiment name containing an extremely large sequence of digits, or an equivalently unbounded artifact_location. The server stores the value because no length check exists. When the UI or listing path later loads that experiment, the client or server spends excessive time processing the string and the panel hangs for other users until the process is recycled or the record is deleted. No named threat actors are tied to this CVE, and public exploit maturity is none.

How to fix it

Upgrade off MLflow v2.13.2 to a release that enforces maximum lengths on experiment names and artifact_location. Independently enforce request and field length limits at the application or reverse-proxy layer for those parameters. Restrict experiment create/rename to trusted identities and do not expose tracking APIs to the public internet. Remove or rename any existing experiments with abnormal name or artifact_location length, then restart UI/tracking workers. If inventory matches the advisory’s package mapping, upgrade github.com/argoproj/argo-workflows/v3 to 3.6.0-rc2 or a later stable release.

How to confirm the fix worked

Confirm deployed MLflow is newer than the affected v2.13.2 line and that create/rename APIs reject oversized experiment names and artifact_location values rather than storing them. Inventory existing experiments for abnormally long names or locations. Confirm Argo Workflows is at 3.6.0-rc2 or later if that Go module is in use. Verify tracking endpoints are not anonymously reachable and that gateway body/header size limits are in effect.

Typical attack path

1. Identify an MLflow tracking server (or equivalent UI) that allows experiment create or rename.
2. Use permitted access—or an unauthenticated/public tracking endpoint if one exists.
3. Create or rename an experiment with an extremely long integer-heavy name, or set an unbounded artifact_location.
4. Trigger UI or listing load of that experiment so the panel becomes unresponsive.
5. Leave the oversized record in place to prolong denial of service for other users.

How to detect it

This is a resource-exhaustion DoS, so look for availability symptoms rather than malware. Review MLflow tracking and reverse-proxy access logs around experiment create/rename and list/get calls for unusually large request bodies or query parameters. Inspect the experiment store (backend database or file store) for names or artifact_location values that are far longer than normal. Correlate UI/worker hangs, timeouts, elevated CPU/memory on the tracking or UI process, and 5xx or client-side freeze reports when loading the experiments panel. There are no associated APT clusters; treat hits as opportunistic abuse or accidental misuse. Historical window: published 2025-03-20 (hundreds of days in the past), so include older logs if retained.

• /api/2.0/mlflow/experiments/create
• /ajax-api/2.0/mlflow/experiments/create
• /api/2.0/mlflow/experiments/update
• /ajax-api/2.0/mlflow/experiments/update
• artifact_location
• mlflow ui
• mlflow server

What your security team should do

• Inventory MLflow tracking servers and any github.com/argoproj/argo-workflows/v3 usage; record versions against v2.13.2 (affected) and 3.6.0-rc2 (listed fix).
• Patch and restart in routine maintenance rather than emergency change unless the UI is internet-exposed or business-critical.
• Lock down experiment create/rename and place tracking APIs behind authentication and network allow-lists.
• Add reverse-proxy or WAF maximum body and field length controls for experiment name and artifact_location.
• Hunt for oversized experiment records and clean them up so a pre-existing payload cannot keep hanging the UI.
• Deprioritize relative to KEV and remotely exploitable RCE issues; EPSS is low and exploit maturity is none.