# CVE-2025-24787: Parameter injection in DB connection URIs leading to local file inclusion in WhoDB

> Attackers can inject parameters into database connection URIs to read local files on the host machine via unsafe string concatenation.

- **Severity:** High 8.6 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 6 Feb 2025
- **Updated:** 6 Feb 2025
- **Also known as:** GHSA-c7w4-9wv8-7x7c, GO-2025-3457

## What is CVE-2025-24787?

CVE-2025-24787 is a high-severity path traversal vulnerability in clidey whodb, published on 6 Feb 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

WhoDB is an open source database management tool. In affected versions the application is vulnerable to parameter injection in database connection strings, which allows an attacker to read local files on the machine the application is running on. The application uses string concatenation to build database connection URIs which are then passed to corresponding libraries responsible for setting up the database connections. This string concatenation is done unsafely and without escaping or encoding the user input. This allows an user, in many cases, to inject arbitrary parameters into the URI string. These parameters can be potentially dangerous depending on the libraries used. One of these dangerous parameters is `allowAllFiles` in the library `github.com/go-sql-driver/mysql`. Should this be set to `true`, the library enables running the `LOAD DATA LOCAL INFILE` query on any file on the host machine (in this case, the machine that WhoDB is running on). By injecting `&allowAllFiles=true` into the connection URI and connecting to any MySQL server (such as an attacker-controlled one), the attacker is able to read local files. This issue has been addressed in version 0.45.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Weakness: CWE-943 (Improper Neutralization of Special Elements in Data Query Logic)

## Which versions are affected by CVE-2025-24787?

3 open source packages ship an affected version, including github.com/clidey/whodb/core. It affects 1 product.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `github.com/clidey/whodb/core` | Go | All versions | 0.0.0-20250127202645-8d67b767e005 |
| `github.com/clidey/whodb/core` | Go | All versions | 0.0.0-20250127202645-8d67b767e005 |
| `github.com/clidey/whodb/core` | Go | All versions | 0.0.0-20250127202645-8d67b767e005 |

Products: Clidey Whodb.

## How do I fix CVE-2025-24787?

Upgrade github.com/clidey/whodb/core to 0.0.0-20250127202645-8d67b767e005 or later.

## Is CVE-2025-24787 being exploited?

It is not confirmed as exploited in the wild, but public exploit code for CVE-2025-24787 exists.

## Other vulnerabilities in clidey whodb

- [CVE-2025-24786](https://insights.sbomify.com/CVE-2025-24786/): Path traversal opening Sqlite3 database in WhoDB (critical 10.0)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2025-24787 and fix it if it is affected.

What it is: CVE-2025-24787 is a high-severity path traversal vulnerability in clidey whodb, published on 6 Feb 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2025-24787 exists.

Affected packages and fixed versions:
- github.com/clidey/whodb/core (Go): affected all versions; fixed in 0.0.0-20250127202645-8d67b767e005
- github.com/clidey/whodb/core (Go): affected all versions; fixed in 0.0.0-20250127202645-8d67b767e005
- github.com/clidey/whodb/core (Go): affected all versions; fixed in 0.0.0-20250127202645-8d67b767e005

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2025-24787/ (Markdown: https://insights.sbomify.com/CVE-2025-24787/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2025-24787
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-24787
- OSV: https://osv.dev/vulnerability/CVE-2025-24787

---
From sbomify Insights: https://insights.sbomify.com/CVE-2025-24787/
Summaries are generated and may contain mistakes; the official description above is the record.