CVE-2025-68472: The Absolute Path to Destruction in MindsDB

MindsDB is a fascinating piece of technology. It bridges the gap between standard databases and Machine Learning, effectively allowing developers to train and query models using standard SQL. It’s complex, it’s powerful, and like many modern data platforms, it exposes a REST API to handle the mundane tasks—like uploading files to be analyzed.

But here is the thing about complex systems: they often trip over the simplest hurdles. In this case, the hurdle was basic file handling in Python. The vulnerability we are looking at today, CVE-2025-68472, isn't some deep memory corruption in a C++ kernel driver. It’s a logic error in how a high-level API processes JSON input.

What makes this specific bug nasty isn't just that you can read files you shouldn't. It's that the mechanism used to read them is destructive. The application doesn't just copy the data; it performs a shutil.move. In the physical world, this is the equivalent of a burglar not just photocopying your passport, but stealing it entirely so you can't leave the country. It’s a theft that doubles as sabotage.

To understand this vulnerability, you have to understand a specific quirk in Python's standard library—a quirk that has bitten security researchers and developers alike for years. The function os.path.join() is the standard way to concatenate directory paths in a cross-platform manner.

However, the documentation contains a warning that developers frequently miss: "If a component is an absolute path, all previous components are thrown away and joining continues from the absolute path component."

In mindsdb/api/http/namespaces/file.py, the developers were handling file uploads. They had secured the multipart form uploads and the URL-based uploads. But for some reason, they left the JSON processing logic wide open. When a user sends a PUT request with a JSON body, the code takes the filename directly from the user input and joins it with a temporary directory path.

If the attacker provides a filename like data.csv, it works as expected: /tmp/mindsdb/data.csv. But if the attacker provides /etc/passwd, Python sees the leading slash (the absolute path), discards the safe temporary directory prefix, and resolves the path simply as /etc/passwd. The application thinks it is working with a temp file, but it is actually holding a handle to a critical system asset.

Let's look at the logic flow that enables this. The vulnerability resides in the PUT handler for the file API. Here is the simplified logic of the vulnerable component:

# mindsdb/api/http/namespaces/file.py
 
# 1. Trusting the client
data = request.json  # Unvalidated JSON input
 
# 2. The Fatal Error
# If data['file'] is "/etc/passwd", file_path becomes "/etc/passwd"
# temp_dir_path is completely ignored.
file_path = os.path.join(temp_dir_path, data["file"])
 
# 3. The Destructive Action
# The system attempts to save/process the file.
# Crucially, later in the logic, it uses shutil.move()
shutil.move(file_path, destination_storage)

The fix, introduced in version 25.11.1, is remarkably simple. It applies the same sanitization logic used elsewhere in the application, likely stripping directory separators and ensuring the filename is just a filename, not a path.

[!NOTE] This vulnerability highlights why "Sanitize Input" is the golden rule. Trusting a raw string from a JSON body in a filesystem operation is practically inviting a breach.

Exploiting this requires no authentication (in default configurations) and no special tooling beyond curl or a Python script. The attack chain is two-fold: first, we move the target file into MindsDB's storage, and second, we query it using SQL.

Step 1: The Heist We send a PUT request. We aren't uploading a file; we are telling MindsDB that a file already exists at a specific path and asking it to ingest it. Because of the absolute path bug, it reaches out to the OS filesystem.

PUT /api/files/stolen_shadow HTTP/1.1
Host: target-mindsdb:47334
Content-Type: application/json
 
{
    "file": "/etc/passwd"
}

When the server processes this, it executes shutil.move('/etc/passwd', '/var/lib/mindsdb/storage/stolen_shadow'). The operating system complies. The /etc/passwd file is now gone from its original location.

Step 2: The Read Now that the file is inside MindsDB's managed storage, it's treated like a CSV or text data source. We can simply ask MindsDB to show us the contents using its SQL API:

POST /api/sql/query HTTP/1.1
Host: target-mindsdb:47334
 
{
    "query": "SELECT * FROM files.stolen_shadow"
}

The server happily returns the contents of the file in JSON format. We have achieved unauthenticated information disclosure and potentially crashed the server simultaneously.

The impact scores for this CVE are interesting. Officially, the confidentiality impact might be debated if looking strictly at the move operation, but practically, this is a High Severity issue.

Confidentiality: Attackers can read configuration files, source code, SSH keys, or AWS credentials stored on the disk. If the MindsDB instance is running in a cloud environment (which it often is), stealing ~/.aws/credentials is game over for the entire cloud infrastructure.

Availability: This is the hidden killer. Because the exploit uses move rather than copy, it performs a Denial of Service. If an attacker targets /bin/bash, /etc/hosts, or MindsDB's own configuration files, the service—or the entire OS—will fail to function correctly. A reboot would likely result in a bricked server requiring manual intervention to restore the missing files.

The remediation is straightforward: Update to MindsDB v25.11.1. The vendor has patched the hole by ensuring that filenames provided in the JSON body are sanitized, stripping out directory traversal characters and absolute path indicators.

If you cannot patch immediately, you have two critical stop-gaps:

1. Network Isolation: Ensure your MindsDB API port (47334) is not exposed to the internet. This should be standard practice, but we all know how often "dev" environments end up on Shodan.
2. Authentication: Enable the built-in authentication mechanisms. While this doesn't fix the code flaw, it requires the attacker to have valid credentials before they can trigger the vulnerable endpoint, significantly reducing the attack surface.

Remember: Input validation isn't a feature; it's a requirement. And Python developers—always sanitize before you join.