Arbitrary Code Execution via Malicious PyFunc Model Deserialization in MLflow

This is a small standalone Go proof-of-concept/operational exploit repository containing README.md, go.mod, and main.go. main.go is the sole executable entry point and implements an end-to-end web attack against an MLflow-backed application. It validates MLflow Basic authentication, obtains an application session through login or fallback registration, uploads a sample hiring CSV to the application's configurable training endpoint, resolves MLflow model/run metadata through the REST API, and overwrites the target model's python_model.pkl artifact. The replacement is a hand-built Python protocol-2 pickle whose REDUCE opcode invokes os.system with a Bash reverse-shell command. After the operator confirms a listener is ready, the tool posts to a configurable prediction URL, relying on the application calling mlflow.pyfunc.load_model() and thereby pickle.load() on the altered artifact. The repository targets CVE-2024-37054 and includes a functional hardcoded reverse-shell payload parameterized only by listener host and port; it is not a detection-only script or a framework module.

This three-file repository contains an MIT license, a detailed README, and one Python entry-point script, mlflow_pickle_rce.py. It is an operational, API-driven proof of concept for MLflow model-registry pickle deserialization leading to remote code execution, described as CVE-2024-37054-style and referencing CVE-2023-6015, CVE-2023-6018, and CVE-2024-37054. The script uses requests with HTTP Basic authentication to test MLflow API access, create or reuse a registered model, create an experiment run, upload an MLmodel manifest and malicious model.pkl, register a model version referencing those artifacts, and optionally transition the version to Production. The pickle executes os.system during unpickling and starts a Python reverse shell to configurable callback parameters. It does not identify a target model automatically or trigger model loading; a separate MLflow UI/API action, prediction service, or scheduled client job must load the registered model for execution to occur. Defaults include admin:password credentials, experiment ID 0, Production stage, and callback port 4444.

This four-file Python proof-of-concept repository targets CVE-2024-37054, an unsafe deserialization condition in MLflow PyFunc model handling. requirements.txt pins MLflow 2.14.1, cloudpickle 3.0.0, and requests 2.32.3. build_model.py is a standalone artifact generator: it saves a nominal MLflow PythonModel and then replaces python_model.pkl with a cloudpickle object whose __reduce__ method resolves to os.system executing a Bash reverse-shell command. exploit.py automates an application-specific exploitation chain against the default SmartHire and MLflow hosts. In --atoz mode it creates a random account and authenticates; otherwise it accepts an existing application session. It uploads a benign CSV to initiate model training, queries MLflow's registered-model search API to identify the resulting run ID, PUTs the malicious python_model.pkl to the run's artifact path using HTTP Basic authentication, and posts another CSV to /predict to cause model loading. Successful deserialization executes in the permissions and network context of the process serving prediction. The repository contains functional exploitation code rather than only detection logic; its callback address and port are supplied at runtime, while the payload itself is a basic Bash reverse shell.

Repository contains a single Python exploit script and a README describing exploitation of CVE-2024-37054 in MLflow pyfunc model loading. The exploit is not part of a major framework. Its core purpose is to achieve remote code execution by replacing the MLflow model artifact python_model.pkl with a malicious cloudpickle payload, then causing an application or workflow to call mlflow.pyfunc.load_model() on that model. The script structure includes: MLflow validation and model enumeration via /api/2.0/mlflow/registered-models/search; optional application login/registration helpers using /login and /register to obtain a session cookie; optional model training logic (partially truncated in provided content) to create/select a target model; run/experiment resolution; payload generation for a reverse shell to attacker-supplied lhost:lport; artifact upload to the MLflow artifacts API path for model/python_model.pkl; and a trigger phase that sends a request to an operator-provided application endpoint expected to load the poisoned model. The exploit is operational rather than a simple detector because it automates authentication, model discovery, payload creation, artifact overwrite, and triggering, with a concrete reverse-shell outcome.

This repository is a small, purpose-built exploit kit for achieving remote code execution through malicious MLflow model registration and pickle deserialization. It contains two Python scripts and supporting documentation/data: generate_model.py creates a malicious model.pkl using a Python pickle gadget via Exploit.__reduce__ that executes os.system() and launches a reverse shell to an attacker-specified host/port; upload_model.py authenticates to an MLflow instance with hardcoded basic credentials, creates an experiment and run, uploads the malicious pickle plus an MLmodel descriptor, registers or reuses a target model name, creates a new model version, and transitions that version to the Production stage. The README explains the full attack chain and shows how to trigger execution by POSTing sample.csv to a downstream /predict endpoint with a valid session cookie. sample.csv is benign trigger data only. The exploit’s main capability is server-side code execution during model loading, resulting in a reverse shell as the application user. The repository is not a framework module, not a detector, and appears to be a functional operational exploit with a hardcoded/basic payload rather than a generalized weaponized tool.

Repository contains a small standalone Python proof-of-concept exploit for CVE-2024-37054, an MLflow deserialization issue. There are 4 files total: a README, two Python exploit/build scripts, and a mislabeled requirements file containing package pins. The code is not part of a known exploit framework. malicious_payload.py is a local builder that creates an MLflow pyfunc model and then overwrites its python_model.pkl artifact with a cloudpickle-serialized object whose __reduce__ returns os.system executing a bash reverse shell. This demonstrates the core vulnerability directly. shell.py is the main operational exploit. It supports either using an existing session cookie or automatically registering and logging into a target web app. It uploads a benign CSV to a training endpoint, extracts the resulting registered model name, queries the MLflow API for the corresponding run_id, uploads a malicious python_model.pkl artifact to the MLflow artifacts API, then triggers the target application's /predict workflow so the vulnerable model load path deserializes the pickle and executes the reverse shell. Default targets are specific to the HTB SmartHire environment: smarthire.htb and models.smarthire.htb. Default MLflow credentials are admin/password. Overall capability: authenticated/adjacent remote code execution via malicious model artifact replacement and deserialization, culminating in a reverse shell. The exploit is operational rather than a simple detector because it includes end-to-end automation and a working payload, but payload customization is limited to attacker host/port.

Small standalone exploit repository containing a single Python proof-of-concept script (poc.py), a README, and license file. The main exploit is poc.py, a CLI-driven Python tool targeting CVE-2024-37054 in MLflow Tracking Server versions prior to 2.14.3. Its purpose is to achieve authenticated remote code execution by replacing the MLflow model artifact python_model.pkl with a malicious pickle payload and then triggering model loading so the server deserializes attacker-controlled data. Repository structure is simple: poc.py implements argument parsing, exploit orchestration, authentication handling, payload generation, artifact overwrite, and RCE trigger logic; readme.md documents vulnerability details, usage, indicators of compromise, and mitigation guidance. The script accepts a target application URL, an MLflow server URL, attacker callback host/port, optional MLflow credentials, optional application credentials, and configurable endpoint paths such as login and upload routes. Based on the visible code and README, the exploit performs a multi-step workflow: optionally authenticate to the front-end application, interact with the application to create or identify an MLflow-backed model/run, authenticate to MLflow, locate the relevant artifact path, upload a malicious pickle over the MLflow artifact API, and finally trigger inference/prediction to force deserialization. Main exploit capability: arbitrary command execution on the MLflow server. The default payload is an operational reverse shell callback to the attacker-supplied LHOST:LPORT; alternatively, the operator can provide a custom shell command. Because the payload uses pickle deserialization and os.system(), this is a real exploit rather than a scanner or detector. It is best classified as OPERATIONAL: it includes a working payload and end-to-end exploitation flow, but it is a standalone PoC rather than a reusable framework module.

This repository provides a Proof of Concept (PoC) exploit for CVE-2024-37054, a critical deserialization vulnerability in MLflow (versions 0.9.0 through 2.14.1). The exploit demonstrates how an attacker can craft and log a malicious MLflow model containing a pickle payload that, when loaded by a victim, results in arbitrary code execution (RCE) on the victim's machine. The repository includes two main Python scripts: 'poc/log_malicious_model.py' (attacker script) and 'poc/load_vulnerable_model.py' (victim script). The attacker script creates and logs a model with a payload that executes an OS command to print a message and create a file ('pwned.txt'). The victim script loads this model from the MLflow server, triggering the payload. The Dockerfile sets up a vulnerable MLflow environment for testing. The main attack vector is network-based, targeting the MLflow tracking server at http://127.0.0.1:5000. The exploit is a functional PoC and does not include weaponized or highly automated features.