CVE Name: CVE-2025-68472
Product: MindsDB (AI training and inference platform)
Severity: High
CVSS Score: ~8.8 (High)
Exploitability: Easy — unauthenticated
Exploit Available: Yes — publicly available proof-of-concept
Impact: Arbitrary file read and disclosure; files moved from original location
Mitigation: Upgrade MindsDB to fixed version
What This Vulnerability Really Is
At a high level, CVE-2025-68472 is a path traversal weakness in the way MindsDB accepts and handles file uploads. There is a specific API endpoint in MindsDB that allows users to upload or reference files by name. The problem was that this endpoint did not clean or validate the file names properly before using them.
Normally, when a web application takes a filename from a user, it should ensure that the name stays within a safe directory — so you don’t accidentally allow someone to access sensitive files on disk. In this case, MindsDB simply joined the user-supplied filename onto an internal processing directory without checks. That means an attacker can send a specially crafted filename that contains ../ sequences or even an absolute path like /etc/passwd, and MindsDB will go fetch that file from the local filesystem.
The end result? An unauthenticated user — meaning no login or token required — can read arbitrary files that the MindsDB process has permission to access. This includes system files, configuration files, secrets, credentials, API keys, private certificates — essentially anything readable by the MindsDB process user.
Even worse, the vulnerable logic moves the target file out of its original location into the application’s internal storage. That means not only can an attacker read it, but the file could end up missing from where it belongs.
How It Can Be Exploited
To exploit this issue, all an attacker needs is network access to the MindsDB API (no password required).
There is a specific URL path used to upload or process files. When that endpoint gets a JSON body with a field named "file", it directly trusts whatever path is given.
A malicious actor can send JSON with something like this:
{
"file": "../../../../../etc/passwd"
}or even:
{
"file": "/root/.ssh/id_rsa"
}MindsDB takes that string, sticks it onto a base folder, and dutifully tries to open it. Since the attacker put in ../ sequences, the actual file that gets opened may be anywhere on disk.
Once that file is “handled” by MindsDB, it becomes visible inside MindsDB’s database or storage. An attacker can then issue a simple query against MindsDB’s internal tables to see the file contents.
The public proof-of-concept that exists shows exactly this workflow:
- Send a crafted file upload request with a malicious path.
- The server reads and moves that file.
- Send a query to list the contents and return them back to the attacker.
Because this requires no credentials and the logic does not validate the path, this is a straightforward, low-effort exploit when the API is reachable.
Why This Is Dangerous in the Real World
A vulnerability like this is more than just a “weird bug.” In real environments, it means:
- Any file readable by the application user is effectively public. If MindsDB runs under a privileged account or has access to critical configuration files, those can be extracted.
- Sensitive credentials could leak. Things like AWS keys, database passwords, private certificates — if they exist on disk where MindsDB runs — become readable.
- Files might disappear from the system. Because the vulnerable code moves the file during processing, that file may no longer be in its original location, causing system instability or data loss.
- No login barrier means easy scanning and exploitation. Automated attackers routinely scan for APIs with known vulnerable paths, and unauthenticated weaknesses are high-priority targets.
Because of these points, even though the vulnerability looks like a simple string manipulation issue, the consequences can be severe.
Proof-of-Concept and Real Exploit Behavior
Any attacker needs only one thing: send a PUT request with a JSON body to the upload endpoint. For example:
PUT /api/files/some_identifier
Content-Type: application/json
{ "file": "/etc/shadow" }After that, the same attacker can issue a second request to query MindsDB’s internal storage table where files are stored. That second request simply asks MindsDB to select the contents of the file that was just processed. The server returns the decoded text.
This two-step process — upload (abuse) + query — is the core of the exploit. It does not require advanced coding skills, special tools, or user sessions.
The public proof-of-concept that exists shows just that, and because it’s straightforward enough, any moderately skilled attacker can reproduce it quickly.
How to Detect Active Exploitation or Attempts
If you are defending a MindsDB installation, your goal is to spot the signs of exploitation quickly. Since this issue revolves around specific JSON values and API paths, there are several ways to detect it.
1. Look at Access Logs
Track every request to the API endpoint that deals with file uploads. Specifically:
- Monitor for HTTP
PUTrequests to paths like/api/files/… - Inspect JSON bodies
- Flag anything where the
filefield contains:../- absolute paths starting with
/ - references to sensitive folders like
/etc,/root,/home
A simple detection rule could be:
If a PUT /api/files/… request has a JSON body where file contains ../ or a leading /, raise a warning.
Even if someone is just probing, that is a suspicious action.
2. Inspect Database Activity
After a suspicious upload attempt, watch for unusual queries like:
SELECT * FROM files.<name>- Queries that retrieve the contents of files that normally should not be in your system
Frequent or odd SELECTs where the data comes from internal file storage may indicate someone trying to read arbitrary data.
3. Watch File System Audit Logs
If your server has auditing enabled (auditd on Linux, or Windows File Access Auditing), look for:
- Files outside of MindsDB’s normal working directory being read or moved
- Changes to system configuration files
- Unexpected file move operations
These events are rare under normal operations but common when an attacker is exploring.
4. Automated Detection Signatures
In raw log sources (like web server logs), you can build simple detection patterns:
Example pattern to flag:
PUT /api/files/AND- JSON parameter
"file"contains../or “/etc/” or “/root/”
This pattern is a strong indicator of path traversal or exploitation attempt.
If you use a SIEM, you can turn that into a rule that alerts when this pattern appears.
What You Should Do Right Now
This vulnerability has a real exploit and no authentication requirement, meaning it is urgent to address.
1. Upgrade MindsDB Immediately
The only reliable way to fix this is to upgrade MindsDB to a patched version where this code path has been corrected. The internal handling now ensures filenames are sanitized and never allow arbitrary paths.
Upgrade link (official):
🔗 https://github.com/mindsdb/mindsdb/security/advisories/GHSA-qqhf-pm3j-96g7
Follow the upgrade instructions in that advisory to make sure your instance is no longer vulnerable.
Temporary Mitigations (Until You Patch)
If upgrading immediately isn’t possible, consider these defensive steps:
- Restrict access to the API — block external access so only trusted internal networks can reach the vulnerable endpoint.
- Place a Web Application Firewall (WAF) in front of the API that blocks JSON bodies containing suspicious paths (
../, absolute paths). - Run MindsDB with limited permissions — have it run under a service account that cannot read sensitive folders.
- Enable auditing — so you can detect if someone tries to exploit the weakness or succeeds.
- Scan logs retroactively — search past logs for suspicious patterns; if you find them, assume compromise and investigate further.
Final Takeaway
CVE-2025-68472 is not just a coding flaw — it’s a real, exploitable security issue with tangible impact. The combination of:
- no authentication,
- use of unvalidated user input for file paths,
- public proof-of-concept,
makes this a high-risk vulnerability.
