Vulnerabilities in pkg:golang/github.com/clidey/whodb/core

PACKAGE
Advisory Identifier: GHSA-c7w4-9wv8-7x7c
Advisory Summary

CVE-2025-24787 is a HIGH (CVSS 8.6) whodb allows parameter injection vulnerability (CWE-943: Improper Neutralization of Special Elements in Data Query Logic) affecting Github.com/clidey/whodb/core libraries in the Go ecosystem. The issue involves whodb allows parameter injection in db connection uris leading to local file inclusion. Remediation is available by upgrading affected packages to version 0.0.0-20250127202645-8d67b767e005.

3 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:golang/github.com/clidey/whodb/core

3 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:golang/github.com/clidey/whodb/core. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-c7w4-9wv8-7x7c CVE-2025-24787 HIGH WhoDB allows parameter injection in DB connection URIs leading to local file inclusion
GHSA-9r4c-jwx3-3j76 CVE-2025-24786 CRITICAL WhoDB has a path traversal opening Sqlite3 database
GHSA-5pf6-cq2v-23ww - HIGH WhoDB Allows Unbounded Memory Consumption in Authentication Middleware Can Lead to Denial of Service

CVE-2025-24787 at a Glance

CVE Identifier CVE-2025-24787
GHSA Identifier GHSA-c7w4-9wv8-7x7c
Severity HIGH
CVSS v3.1 Base Score 8.6
CWE Classification CWE-943: Improper Neutralization of Special Elements in Data Query Logic
Affected Product Github.com/clidey/whodb/core
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 8.6

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2025-24787

To remediate this vulnerability, upgrade all affected Github.com/clidey/whodb/core dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/clidey/whodb/core fixed: 0.0.0-20250127202645-8d67b767e005
Upgrade github.com/clidey/whodb/core to 0.0.0-20250127202645-8d67b767e005
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/clidey/whodb/core

How to Check if You Are Affected

To determine whether your application is affected by CVE-2025-24787, inspect your project dependencies for Github.com/clidey/whodb/core:

inspect dependencies for github.com/clidey/whodb/core

Analyze the terminal output to locate any version of Github.com/clidey/whodb/core in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.0.0-20250127202645-8d67b767e005), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-943: Improper Neutralization of Special Elements in Data Query Logic, where the product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query. In Github.com/clidey/whodb/core, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary 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. ### Details 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). Source: https://github.com/go-sql-driver/mysql/blob/7403860363ca112af503b4612568c3096fecb466/infile.go#L128 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. ### PoC As this vulnerability does not require sending requests manually and can all be done using the WhoDB UI, screenshots are provided instead of HTTP requests. For this proof-of-concept, a clean instance of WhoDB and MySQL were set up using podman (docker is a suitable alternative): ``` podman network create whodb-poc podman run -d -p 8080:8080 --network whodb-poc docker.io/clidey/whodb podman run -d --name mysql -e MYSQL_ROOT_PASSWORD=password --network whodb-poc docker.io/mysql:9 ``` The attacker connects to the database via WhoDB. Note that in the `Loc` field, the string `&allowAllFiles=true` is inserted: ![2025-01-21-13-28-08](https://github.com/user-attachments/assets/28709707-97e4-4d26-b61c-5462db6dd43f) After connecting, the attacker navigates to the scratchpad in `/scratchpad`. The attacker first creates a demo table: ```sql CREATE TABLE poc ( line TEXT ); ``` The attacker then enables loading files from the server side. For the sake of clarity, do note that while this is required, the file is not being read from the remote server where MySQL is running, but the local machine that WhoDB is running on. ```sql SET GLOBAL local_infile=1; ``` The attacker then uses the `LOAD DATA LOCAL INFILE` statement to read the contents of `/etc/passwd` (in this case from inside the container where WhoDB is running) into the previously created table: ```sql LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE poc FIELDS TERMINATED BY '\0' LINES TERMINATED BY '\n'; ``` The attacker then navigates to the `poc` table in the _Tables_ view and observes that the file has been read successfully: ![2025-01-21-14-04-47](https://github.com/user-attachments/assets/c8f499ce-0d40-49ba-a2c6-fe2d12c677c5) ### Impact While this proof-of-concept demonstrates local file inclusion, the root cause of the issue is the unsafe construction of database connection URIs from user input. Not all database connector libraries used in WhoDB were inspected; there may be libraries which allow for even more impactful parameters. The attack requires no user authentication to WhoDB (only authentication to any database server, such as an attacker-controlled one) and no special configuration - the default configuration of the application is vulnerable.

CVE-2025-24787 Affected Github.com/clidey/whodb/core Versions

1 component(s)
Fixed Versions:
0.0.0-20250127202645-8d67b767e005
Product / Package Ecosystem Affected Versions Fixed Version
github.com/clidey/whodb/core
Go
< 0.0.0-20250127202645-8d67b767e005
0.0.0-20250127202645-8d67b767e005

References

Frequently Asked Questions

What is CVE-2025-24787?
CVE-2025-24787 is a security vulnerability in Github.com/clidey/whodb/core involving WhoDB allows parameter injection in DB connection URIs leading to local file inclusion under CWE-943: Improper Neutralization of Special Elements in Data Query Logic.
Which Github.com/clidey/whodb/core versions are affected?
Affected versions include releases prior to 0.0.0-20250127202645-8d67b767e005 across affected packages: github.com/clidey/whodb/core.
What version fixes CVE-2025-24787?
Upgrading to 0.0.0-20250127202645-8d67b767e005 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/clidey/whodb/core affected?
Yes, github.com/clidey/whodb/core is affected in releases prior to 0.0.0-20250127202645-8d67b767e005. Upgrade your dependency to 0.0.0-20250127202645-8d67b767e005 or later.
What is the CVSS score of CVE-2025-24787?
CVE-2025-24787 has a CVSS v3.1 base score of 8.6 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N.
What CWE is associated with CVE-2025-24787?
CVE-2025-24787 is classified under CWE-943: Improper Neutralization of Special Elements in Data Query Logic (The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query.).
How can I check Go dependencies for CVE-2025-24787?
Run the dependency tree command: 'inspect dependencies for github.com/clidey/whodb/core'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-c7w4-9wv8-7x7c",
  "modified" : "2025-02-07T17:35:21Z",
  "published" : "2025-02-06T19:58:37Z",
  "aliases" : [ "CVE-2025-24787" ],
  "summary" : "WhoDB allows parameter injection in DB connection URIs leading to local file inclusion",
  "details" : "### Summary\n\nThe 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.\n\n### Details\n\nThe application uses string concatenation to build database connection URIs which are then passed to corresponding libraries responsible for setting up the database connections.\n\nThis 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.\n\nOne 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). Source: https://github.com/go-sql-driver/mysql/blob/7403860363ca112af503b4612568c3096fecb466/infile.go#L128\n\nBy 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.\n\n### PoC\n\nAs this vulnerability does not require sending requests manually and can all be done using the WhoDB UI, screenshots are provided instead of HTTP requests.\n\nFor this proof-of-concept, a clean instance of WhoDB and MySQL were set up using podman (docker is a suitable alternative):\n\n```\npodman network create whodb-poc\npodman run -d -p 8080:8080 --network whodb-poc docker.io/clidey/whodb\npodman run -d --name mysql -e MYSQL_ROOT_PASSWORD=password --network whodb-poc docker.io/mysql:9\n```\n\nThe attacker connects to the database via WhoDB. Note that in the `Loc` field, the string `&allowAllFiles=true` is inserted:\n\n![2025-01-21-13-28-08](https://github.com/user-attachments/assets/28709707-97e4-4d26-b61c-5462db6dd43f)\n\nAfter connecting, the attacker navigates to the scratchpad in `/scratchpad`.\n\nThe attacker first creates a demo table:\n```sql\nCREATE TABLE poc (\n    line TEXT\n);\n```\n\nThe attacker then enables loading files from the server side. For the sake of clarity, do note that while this is required, the file is not being read from the remote server where MySQL is running, but the local machine that WhoDB is running on.\n```sql\nSET GLOBAL local_infile=1;\n```\n\nThe attacker then uses the `LOAD DATA LOCAL INFILE` statement to read the contents of `/etc/passwd` (in this case from inside the container where WhoDB is running) into the previously created table:\n```sql\nLOAD DATA LOCAL INFILE '/etc/passwd'\nINTO TABLE poc\nFIELDS TERMINATED BY '\\0'\nLINES TERMINATED BY '\\n';\n```\n\nThe attacker then navigates to the `poc` table in the _Tables_ view and observes that the file has been read successfully:\n\n![2025-01-21-14-04-47](https://github.com/user-attachments/assets/c8f499ce-0d40-49ba-a2c6-fe2d12c677c5)\n\n### Impact\n\nWhile this proof-of-concept demonstrates local file inclusion, the root cause of the issue is the unsafe construction of database connection URIs from user input. Not all database connector libraries used in WhoDB were inspected; there may be libraries which allow for even more impactful parameters.\n\nThe attack requires no user authentication to WhoDB (only authentication to any database server, such as an attacker-controlled one) and no special configuration - the default configuration of the application is vulnerable.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/clidey/whodb/core"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.0.0-20250127202645-8d67b767e005"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/clidey/whodb/security/advisories/GHSA-c7w4-9wv8-7x7c"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-24787"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/clidey/whodb/commit/8d67b767e00552e5eba2b1537179b74bfa662ee1"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/clidey/whodb"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/go-sql-driver/mysql/blob/7403860363ca112af503b4612568c3096fecb466/infile.go#L128"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-943" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-02-06T19:58:37Z",
    "nvd_published_at" : "2025-02-06T19:15:20Z"
  }
}