CVE-2025-12237 is a high SQL injection flaw in projectworlds Advanced Library Management System 1.0, in /index.php through the keywords parameter. NVD scores it 7.3. The record names no fixed version and says a public exploit exists, so patch the code with parameterised queries and limit who can reach the app.
What's affected
The NVD record names projectworlds Advanced Library Management System version 1.0. The affected code is the file /index.php, and the argument that matters is keywords. The vector needs no privileges. The entry point is the application's front page, so anyone who can open the site can reach the code.
The record says the attack can be launched remotely and that the exploit has been made public. It does not give a patched version. The record does not say whether the maintainer plans a fix, so do not wait for one.
If you run it, treat the code as yours. The fix is a change to the query in that file, and a developer can make it.
How to check if you're exposed
- Find out whether the application runs anywhere in your estate, including test servers, student projects and forgotten demos. A search of your web roots for the file name is quick:
find /var/www -name "index.php". - Open that file in your own copy and look for the keywords value being placed directly into a query string. If it is joined into SQL text with a dot or a plus sign and not bound as a parameter, the code has the flaw.
- Check the application's database account. If it connects as a database administrator or owns more tables than it needs, the impact of any injection is larger.
- Search your web server logs for requests to that file with unusual characters in the keywords value, which will tell you whether anyone has probed it.
A static analysis scan of the source finds this pattern well. Every injectable query tends to look the same to a code scanner.
What to do now
- If this app is not needed, take it offline. Sample applications rarely belong in production.
- If you need it, change the query in index.php to use a prepared statement, and bind the keywords value as a parameter. For example, with mysqli:
$stmt = $conn->prepare("SELECT * FROM items WHERE id = ?");
$stmt->bind_param("s", $value);
$stmt->execute();
- Repeat the change for every other query in the application. A flaw in one file usually has siblings.
- Give the database account only the rights the app needs, and keep it away from other databases.
- Put the app behind a login or an IP allow list, and add a web application firewall rule as a stopgap, not as the fix.
- Check back for a vendor update, since the record lists none.
Why it matters
The weaknesses are CWE-89, SQL injection, and CWE-74, injection in general. They arise when untrusted input becomes part of a command that another system interprets. The database cannot tell the developer's SQL from the attacker's, so it runs both.
A library system keeps member records and loan history. Those are personal data in most jurisdictions, and a front page that accepts a search term is the natural place for this bug to live. Search boxes are a favourite for injection because developers build the query from the text that the user typed.
The record does not mark this CVE as exploited and it is not in the CISA Known Exploited Vulnerabilities catalog. It does say a public exploit exists. Small applications like this are easy targets for automated scanning because their file names and parameters are public.
Quick check
Is there a patched version of projectworlds Advanced Library Management System?
The NVD record names none. Fix the query yourself with a prepared statement, or remove the application.
Does a web application firewall fix SQL injection?
It can block many known attack strings, which buys time. It does not fix the code. Prepared statements are the real fix.
Sources
Last reviewed: 19 October 2026.
