CVE-2025-7179 is a high severity (CVSS 7.3) SQL injection in Library System 1.0 from code-projects. The /add-teacher.php file builds a database query from the Username parameter without safe handling. No fixed version is confirmed, so remove public access or rewrite the query with prepared statements.
What's affected
The record names Library System 1.0 from code-projects as the affected product. The weak spot is /add-teacher.php, which handles the form that adds a teacher account. The record lists version 1.0 as affected. It names no fixed version, and neither the record nor the public report I read points to a patch. I could not confirm a fix, so check the vendor page before assuming one exists.
The record says the attack can be launched remotely and that the exploit details have been disclosed to the public. It does not say the flaw is exploited in the wild, and it is not in the CISA Known Exploited Vulnerabilities catalog (the record's KEV flag is false). The CVSS vector in the record (PR:N) says no privileges are needed to reach it.
The description text, which follows the VulDB wording, calls this issue "critical". The CVSS 3.1 base score in the record is 7.3, which is high on the CVSS scale. Both are in the record, so you will see the word critical in some feeds next to a high score. This post uses the score.
The weaknesses are listed as CWE-74 and CWE-89. The first is the broad class (injection into a downstream component). The second is the specific case of SQL commands built from untrusted input.
How to check if you're exposed
Because the weakness is in the application code itself, the quickest check is a search of your own deployment. Locate the file first:
grep -rn "add-teacher.php" /var/www/
Open the file and look at how the Username parameter reaches the database call. If the value is joined into a query string, the code matches the report. Then check whether the application is reachable from the internet or from networks you do not control. Admin pages are not safe just because the link is not published.
To look for signs of probing, search your web server access log for requests to that path that carry quote characters or SQL keywords in the query string or form data:
grep "add-teacher.php" /var/log/apache2/access.log | grep -iE "%27|union|select|sleep"
A hit does not prove a compromise, and a clean log does not prove safety, since POST bodies are usually not logged. Treat the log search as a hint only.
What to do now
- Find every copy of Library System you run, including test and demo installs.
- If it holds real data, take it off the public internet until the code is fixed.
- Replace string built queries in
/add-teacher.phpwith prepared statements, using PDO or mysqli parameter binding, and validate the type of theUsernameparameter. - Run the application's database user with the least rights it needs, so a bad query cannot read or change other tables.
- Rotate any credentials stored in the database if you suspect probing, and review the data for unexpected changes.
- Check the vendor page and the public report for a patch before you ship your own, and record the decision.
Why it matters
SQL injection happens when user input becomes part of a query's structure instead of staying as plain data. The database cannot tell the difference, so a crafted value can change what the query does. The usual cure is simple and old: pass values as bound parameters so they are never parsed as SQL.
This case is typical of small PHP applications that ship as downloadable projects. They are easy to deploy, rarely get a security review, and often have no maintainer who issues patch releases. That is why the missing fixed version matters more than the score. Without a patch, the choice is to fix the code yourself or stop running it.
Quick check
Is there a patch for CVE-2025-7179?
None is confirmed. The record lists version 1.0 as affected and names no fix. Check the vendor page, and expect to fix the query in your own copy.
Will a dependency scan find this?
No. The flaw is in the application's own code, not in a third party package. A dependency scan such as the free in-browser Safeguard scan covers the libraries an application pulls in, and code level flaws need code or runtime testing as well.
Sources
Last reviewed: 18 October 2026.
