MindsDB's Moving Day: How a JSON Payload Evicted /etc/passwd

MindsDB is the cool kid on the block for developers who want to sprinkle some "AI magic" onto their existing databases without learning PyTorch. It acts as a virtual database, sitting between your application and your data, allowing you to run SQL queries that train models or make predictions. It’s powerful, it’s convenient, and as it turns out, it was a little too eager to help you manage your files.

Deep within the mindsdb/api/http/namespaces/file.py module lies a feature designed to let users upload datasets (CSVs, JSONs) to be used as tables. Typically, this is where you'd upload your sales history to predict next quarter's revenue. But thanks to CVE-2025-68472, this feature became a weapon of mass destruction for the local filesystem.

The vulnerability isn't just a standard "read-only" path traversal where I peek at your config files. This is a "move" operation. The application takes the file you specify and relocates it to its own internal storage. If you point it at a system file, MindsDB doesn't just read it; it evicts it. It’s the digital equivalent of a moving company showing up to the wrong house and stripping the copper wiring because someone signed a work order with the address "/root".

To understand this bug, you have to understand one specific quirk of Python's standard library that has bitten more developers than I can count. The function os.path.join() is supposed to intelligently combine path components. You give it a directory, a filename, and it gives you a path. Simple, right?

However, the documentation—which nobody reads until they've been hacked—states clearly: "If a component is an absolute path, all previous components are thrown away and joining continues from the absolute path component."

This means if I write:

os.path.join("/safe/temp/dir", "/etc/passwd")

Python doesn't give me /safe/temp/dir/etc/passwd. It sees that second argument starts with a slash, assumes I know what I'm doing, and returns /etc/passwd. It discards the safe directory entirely. The developers at MindsDB handled multipart/form-data uploads correctly, sanitizing filenames. But for JSON-based requests, they missed a spot. They took the input straight from the JSON body and fed it to this function. It's like locking your front door with a deadbolt but leaving the back wall missing.

Let's look at the crime scene in mindsdb/api/http/namespaces/file.py. The handlers for standard file uploads were actually checking filenames. But the logic for handling a JSON PUT request looked something like this:

# The Vulnerable Logic
if 'file' in data:
    # data is the raw JSON body
    file_path = os.path.join(temp_dir_path, data['file'])
    # ... later ...
    shutil.move(file_path, destination)

See that? data['file'] is controlled entirely by the user. If I send {"file": "/etc/passwd"}, file_path becomes /etc/passwd. The code then proceeds to use shutil.move to relocate that file into MindsDB's storage directory.

The fix, introduced in version 25.11.1, was simple but effective. They forced the input through a sanitization function (similar to secure_filename) or essentially treated the input as a base filename rather than a path:

# The Fix (Conceptual)
filename = secure_filename(data['file'])
file_path = os.path.join(temp_dir_path, filename)

Now, if I send /etc/passwd, it gets stripped down to just passwd (or similar), and the join results in /safe/temp/dir/passwd. The attack fails because that file doesn't exist in the temp directory.

Exploiting this is terrifyingly simple. We don't need complex shellcode or heap grooming. We just need curl. Since the API endpoint was unauthenticated by default in older versions, we can walk right in.

Here is the attack chain:

1. Recon: Identify a MindsDB instance exposing port 47334/47335.
2. The Payload: Construct a JSON body pointing to a critical system file.

curl -X PUT http://target:47334/api/files/sys_config \
     -H "Content-Type: application/json" \
     -d '{"file": "/etc/passwd"}'

3. The Execution:

   • The server receives the request.
   • os.path.join resolves the path to /etc/passwd.
   • shutil.move('/etc/passwd', '/var/lib/mindsdb/files/sys_config') runs.

4. The Aftermath:

   • DoS: The Linux server now has no /etc/passwd. SSH logins fail. New processes might fail to start if they need user resolution. The system is effectively bricked until an admin boots into recovery mode.
   • Disclosure: The attacker can now query the file contents via MindsDB's SQL interface: SELECT * FROM files.sys_config.

It’s a "two-for-one" special: you steal the secrets and you destroy the server's ability to function.

While the CVSS score sits at a high 8.1, the operational impact of this vulnerability is severe. In a standard path traversal (Information Disclosure), the victim still has their data. Here, the data is stolen and erased from its source.

Imagine an attacker targeting /var/lib/mysql/ibdata1 or a web application's config.php. They aren't just reading your database credentials; they are deleting the configuration file that makes your website work. This transforms a confidentiality breach into a high-impact availability incident.

Furthermore, because MindsDB is often deployed in containerized environments (Docker/Kubernetes), the impact might be limited to the container. However, if the container is running as root (a common sin) and has volumes mounted from the host (e.g., -v /etc:/mnt/host_etc), an attacker could potentially wipe files on the host system itself, escaping the ephemeral nature of the container.

If you are running MindsDB < 25.11.1, you are vulnerable. The remediation is straightforward:

1. Patch: Upgrade to MindsDB v25.11.1 immediately. This version introduces proper filename sanitization for JSON payloads and enforces stricter authentication checks.
2. Network Segmentation: Never expose the MindsDB management API (ports 47334/47335) to the public internet. These should be internal-only, ideally behind a VPN or strictly allowed IPs.
3. Least Privilege: Ensure the MindsDB process does not run as root. Create a dedicated mindsdb user with limited filesystem access. If the process can't read /etc/passwd, it can't move it.

> [!NOTE] > Even with the patch, audit your mindsdb_config.json. Ensure http_auth_enabled is set to true. Relying on "nobody knows this port is open" is not a security strategy; it's a prayer.