CVE-2025-14940 is a high severity SQL injection flaw (CVSS 7.3) in code-projects Scholars Tracking System 1.0. The the ID argument handled by /admin/delete_user.php is used in a database query without safe handling. The record lists no fixed version, so restrict access now and rewrite the query with prepared statements.
What's affected
The record names code-projects Scholars Tracking System 1.0. The vulnerable file is /admin/delete_user.php, and the argument involved is the ID argument.
Here is what the record and its scoring say:
- Severity: High, CVSS 7.3, vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. - Network reachable, low complexity, no privileges and no user interaction required, according to that vector.
- Impact is scored as low for each of confidentiality, integrity and availability.
- The file sits under an admin path, but the vector still scores no privileges required. Do not assume a login screen protects it until you have tested your own deployment.
- Fixed version: none listed in the record.
- Exploitation in the wild: the record is not in the CISA KEV catalog. It does say exploit details have been made public.
A public write up exists on GitHub and is linked from the record. This post does not reproduce its test details.
How to check if you're exposed
This is application code, not a package you install from a registry, so start with a file search on the server or in your repositories.
# Is the application present?
grep -ril "delete_user.php" /var/www 2>/dev/null
# Does your web server log show traffic to the page?
grep "delete_user.php" /var/log/nginx/access.log | tail -n 50
Then open delete_user.php and find where ID is read. If its value is joined into an SQL string, you have the flaw described here. If it is passed to a prepared statement as a bound value, that path is not affected by this class of bug.
Also look at the log lines for unusual characters or very long values in the query string. Odd entries are a prompt to investigate, not proof of compromise.
What to do now
- Find every copy of the application, including test and staging servers.
- Take it off the public internet, or put it behind a VPN or an IP allow list, until the code is fixed.
- Check the vendor site for a patched release. The record lists none, so do not assume one exists.
- Rewrite the query in
delete_user.phpso values are bound as parameters, never joined into the SQL text. - Give the application's database account only the rights it needs. It should not own the schema or read unrelated tables.
Why it matters
SQL injection is the case where an application builds a database command from text it did not control. CWE-89 describes exactly that: special elements in input are not neutralized before the query is built. The parent class, CWE-74, covers injection into any downstream component. Once input can change the shape of a query, the database stops being limited to what the developer meant to ask.
Quick check
Is there a patched version of Scholars Tracking System?
The CVE record lists no fixed version and the references I could see are not a vendor patch. Check code-projects's site, and do not rely on a release number alone. Fixing the query in your own copy is the dependable route.
Is this being exploited in the wild?
The record is not in CISA KEV, and nothing I read says exploitation has been confirmed. It does say exploit details have been made public, so treat exposure as real.
Sources
Last reviewed: 19 October 2026.
