CVE-2024-27134

What it actually does

MLflow’s spark_udf() path creates working directories with overly broad permissions. A local user can win a time-of-check/time-of-use race on those directories and cause later Spark/MLflow work to run under a more privileged identity. The flaw is local only and is reachable solely when spark_udf() is invoked; other MLflow APIs are not implicated.

Why it matters to the business

On shared ML or Spark hosts, a low-privilege user could inherit the rights of the training or serving process and reach models, datasets, or job credentials. Real-world urgency is low: exploitation maturity is none, the CVE is not in CISA KEV, it is not tied to ransomware, EPSS remains about 0.0012 with no 30-day increase, and it has been public for well over a year without a known campaign. Risk concentrates on multi-tenant notebooks, shared clusters, and CI runners that actually call spark_udf().

How an attack unfolds

An attacker who already has an unprivileged local account on a host that runs MLflow with Spark waits for—or induces—a spark_udf() call. That call creates a directory with excessive permissions. During the brief window between permission setup and use, the attacker substitutes or re-owns the directory so subsequent UDF serialization or execution runs with the MLflow/Spark process privileges. Success yields local privilege escalation only; it does not by itself provide remote code execution or unauthenticated network access. No named APT groups or ransomware operators are associated with this issue.

How to fix it

Upgrade MLflow to a build that includes commit 07fdad09eabc63f39069de1ab4cf561da306159f (the upstream fix for excessive directory permissions in the spark_udf path). Pin and redeploy that version across training clusters, notebooks, and pipelines that import mlflow. If you cannot patch immediately, stop calling spark_udf() on shared hosts, isolate Spark/MLflow jobs on dedicated nodes, and ensure job working directories are not world-writable. Ignore unrelated Ubuntu “terminology” package entries in the same advisory feed unless that package is actually installed; the vulnerability described here is in MLflow.

How to confirm the fix worked

Inventory Python environments and container images for the mlflow package and whether code or jobs call spark_udf(). Confirm installed MLflow contains commit 07fdad09eabc63f39069de1ab4cf561da306159f (or a later release that includes it). After upgrade, exercise a non-production spark_udf() job and verify working directories are created with restrictive ownership and mode. On shared hosts, check that unprivileged users cannot write to Spark/MLflow temp or UDF staging directories used at runtime.

Typical attack path

1. Obtain an unprivileged local shell on a host that runs MLflow together with Spark.
2. Confirm that workloads invoke MLflow spark_udf() (the only in-scope trigger).
3. Race the creation and use of the overly permissive working directory used by spark_udf().
4. Cause the privileged Spark/MLflow process to consume attacker-controlled directory contents.
5. Operate with the elevated identity of that process (access data, models, or job secrets on the host).

How to detect it

This is a local race, so evidence is on the host rather than at the perimeter. Review MLflow and Spark driver/executor logs around spark_udf() for unexpected working-directory creation, permission or ownership changes, and failed or retried UDF staging. Inspect audit logs (for example auditd/sysmon-style process and file events) for unprivileged users creating, renaming, or chmod/chowning directories that a Spark or MLflow worker process then uses. Look for sudden privilege changes of Spark/MLflow worker processes and for non-service accounts writing into job temp or UDF staging paths. There are no public exploit kits, ransomware notes, or named actor tooling to hunt; absence of those artifacts does not prove the race was not attempted.

• spark_udf
• mlflow.pyfunc.spark_udf
• mlflow.spark
• ToCToU
• chmod 777
• world-writable

What your security team should do

• Patch MLflow to the fixed git revision 07fdad09eabc63f39069de1ab4cf561da306159f (or a later release that contains it) on every cluster and image that still ships an affected build.
• Prioritize shared, multi-tenant Spark/MLflow hosts; single-user workstations that never call spark_udf() are lower risk.
• Temporarily disable or gate spark_udf() usage until patched, and run remaining Spark jobs under least-privilege service accounts.
• Harden host temp and job directories (restrictive umask, no world-writable staging paths) as a compensating control.
• Treat this as a standard local-privilege-escalation patch rather than an emergency KEV-style outage: EPSS is ~0.0012 and stable, with no known in-the-wild exploitation.