CVE-2025-24787
Clidey Whodb ≤ 0.45.0
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:NSummary
CVE-2025-24787 is a high-severity Improper Neutralization of Special Elements in Data Query Logic (CWE-943) vulnerability in Clidey Whodb. Its CVSS base score is 8.6 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 43th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2025-24787 affects WhoDB, an open source database management tool, in versions prior to 0.45.0. The vulnerability stems from unsafe string concatenation when building database connection URIs, without properly escaping or encoding user input. This enables parameter injection into the URI, particularly dangerous when using the github.com/go-sql-driver/mysql library, where parameters like allowAllFiles=true can be injected to enable execution of LOAD DATA LOCAL INFILE queries on arbitrary local files.
Any unauthenticated network attacker (PR:N) with the ability to supply input influencing the database connection string can exploit this issue. By injecting &allowAllFiles=true into the URI and connecting to any MySQL server—including one controlled by the attacker—the exploiter can read arbitrary files on the host machine running WhoDB. The CVSS v3.1 base score of 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) reflects high confidentiality impact with changed scope, stemming from CWE-943 (improper neutralization of special elements in data query logic).
The GitHub security advisory (GHSA-c7w4-9wv8-7x7c) confirms the issue has been fixed in WhoDB version 0.45.0, urging all users to upgrade immediately. No workarounds are available.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-3947
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Input validation directly stops unneutralized special elements from reaching query logic.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require parameterized queries and input neutralization to prevent query-logic injection.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development catches injection vulnerabilities before release but does not itself implement the fix.
Secure development life cycle mandates input validation and query parameterization that directly prevent injection flaws.
Application security requirements explicitly call for controls against injection and improper query construction.
Secure architecture principles reduce the likelihood of query-logic flaws but do not prescribe the specific coding practice.
Secure coding standards require proper neutralization of special elements in all data queries.
Outsourced development agreements can require secure coding practices, indirectly mitigating the weakness.