CVE-2023-7110 is a SQL injection in the student login page of code-projects Library Management System 2.0. It scores 7.3 (High), needs no prior access, and the record says the exploit is public. No fixed version is listed, so remove it from public networks and parameterize its queries.
What's affected
The record lists Library Management System 2.0 from code-projects. The affected file is login.php at the application root, and the argument is student.
No fixed version is given. The record says the exploit has been disclosed and may be used. The KEV flag is false and I found no advisory describing exploitation in the wild.
Severity note: the description calls it critical (VulDB, VDB-249005), and NVD gives 7.3, High. The title follows the score.
This is the sibling of CVE-2023-7109, which sits in the admin login of the same product. Fixing one and forgetting the other leaves the app open.
How to check if you're exposed
This is a self-hosted PHP app, so the check is local.
find . -name login.php
grep -n "student" login.php
If the student value is joined into a query string, you are exposed. Review the student table for unexpected rows and check the web log for odd values in the login form field.
What to do now
- Restrict the application to your internal network or a VPN until it is fixed.
- Replace every string built query in login.php with a prepared statement, and do the same in admin/login.php (see CVE-2023-7109).
- Search the rest of the code for the same pattern, since a project with two injectable logins usually has more.
- Reset student and admin passwords if the app was public.
- Look for a supported replacement. The record gives no sign of a vendor patch.
Why it matters
SQL injection is the classic result of building a database query by joining strings, so that a value the user supplied can change the meaning of the query instead of being treated as plain data. The weakness class is CWE-89. The durable fix is not a filter for bad characters. It is parameterized queries, where the query text and the values travel separately and the database never confuses one for the other.
Beyond the code fix, the account the application uses to talk to the database matters. An app that connects with broad rights turns a small bug into a large one. A narrowly scoped database user limits what a successful injection can read or change.
Student logins often reuse the passwords people use elsewhere. If the database is read through an injection, those hashes and any weak passwords become someone else's problem too.
Quick check
Is this the same bug as CVE-2023-7109?
Same class and same product, different file. CVE-2023-7109 is in admin/login.php, and this one is in login.php.
Can a firewall alone protect me?
It can reduce exposure by limiting who can reach the page, but the code flaw remains. Parameterized queries are the real fix.
Sources
Last reviewed: 19 October 2026.
