Safeguard
Vulnerability Analysis•

CVE-2025-14211: High SQL Injection in projectworlds Library System

CVE-2025-14211: high SQL injection in projectworlds Library System. No fix is listed, so limit exposure, use prepared statements or retire it.

Safeguard Security Team
5 min read

CVE-2025-14211 is a high severity SQL injection (CVSS 7.3) in projectworlds Advanced Library Management System, version 1.0. The flaw sits in /delete_book.php, where the book_id parameter reaches a database query unsafely and can be abused over the network. The record lists no fixed release, so limit exposure now and plan to patch the query or replace the application.

This post covers what the record says, how to check whether you run the affected code, and what to do while no vendor fix is on file. The weakness is tracked as CWE-89 (SQL injection), a child of CWE-74 (injection). The entry for this CVE is on the Gold page for CVE-2025-14211.

What's affected

  • Product: projectworlds Advanced Library Management System.
  • Affected version: 1.0.
  • Affected file: /delete_book.php, parameter book_id.
  • Fixed version: none is named in the record. Check the product page and the public report listed under Sources before assuming a patch exists.
  • 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.
  • Known Exploited Vulnerabilities (KEV) status: not listed in CISA KEV.

The vector tells you how this is reached: over the network, with low attack complexity and no user interaction. Some of these records need a logged in user (the privileges required field in the vector shows which). Either way, the description says the attack can be started remotely and that a public disclosure exists.

How to check if you're exposed

Because this is a standalone web application rather than a library from a package registry, a normal dependency manifest will usually not list it. It gets deployed by copying files to a web server, so the only reliable inventory is your own list of what runs where.

Work through these checks:

  1. Search your inventory, repositories and web server document roots for the product name and for the file delete_book.php.
  2. If you find it, open the file and read how book_id reaches the SQL statement. A query built by joining strings is the pattern to look for.
  3. Look at your web server access logs for requests to that file from addresses you do not recognize, and at database logs for errors or unusually shaped queries around the same time.
  4. Check which database account the application uses and what it can read and change.

Our free in-browser dependency scan covers packages declared in a manifest. It will not see a copy of this application dropped into a web root, so the file search above is the part that counts.

What to do now

  1. Find every copy of projectworlds Advanced Library Management System you run, including test and demo installs.
  2. If it is internet facing and not essential, take it offline or put it behind a login, a VPN or an IP allow list.
  3. Replace string built SQL in delete_book.php with prepared statements and bound parameters, and review neighboring files for the same pattern, since the code base likely repeats it.
  4. Reduce the database account to the minimum rights the application needs, and make sure it cannot reach other databases.
  5. Rotate any credentials stored in the application database if you have reason to think it was queried by someone else.
  6. Watch the project and the NVD record for a fixed release, and if none appears, plan to retire the application.

Why it matters

This is the classic injection pattern: a request value is concatenated into SQL. What an attacker can reach depends on the database account the application uses and on what that database holds, which is why least privilege and parameterized queries matter more than any filter in front of the page.

The record gives this a base score of 7.3, and a public write up exists, so the effort needed to find and misuse the issue is low. The scope of the damage is whatever the application's database account can reach, which for small apps is often everything in the schema, including user records and password hashes.

For an unmaintained application the practical risk is time. A fix that nobody ships stays open, and scanners and attackers both find old code by its public identifiers. Treat the file and parameter named in the record as a pointer to a wider pattern, not as the only affected spot.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Is there a patch for CVE-2025-14211?

The record does not name a fixed version. Read the public report and the project page for the current state, and if nothing is published, fix the query yourself or retire the application.

Is CVE-2025-14211 exploited in the wild?

The record does not mark it as exploited. It is not in CISA KEV. The description does say a public disclosure exists, so the issue should be treated as easy to find.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.