CVE-2025-14989: High SQL Injection in Beauty Parlor Mgmt System

CVE-2025-14989 is a high severity SQL injection flaw (CVSS 7.3) in Campcodes Complete Online Beauty Parlor Management System 1.0. A request parameter handled by /admin/search-invoices.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 Campcodes Complete Online Beauty Parlor Management System 1.0. The vulnerable file is /admin/search-invoices.php, and the argument involved is not named in the record.

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 "search-invoices.php" /var/www 2>/dev/null

# Does your web server log show traffic to the page?
grep "search-invoices.php" /var/log/nginx/access.log | tail -n 50

Then open search-invoices.php and look at every request value that ends up in an SQL string. The record does not name the argument, so review the whole file.

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.

If the application lives in a repository you track, the free in-browser dependency scan will list known CVEs for the packages it can identify. A hand copied PHP project often has no manifest at all, so an inventory by hand is still needed.

What to do now

1. Find every copy of the application, including test and staging servers.
2. Take it off the public internet, or put it behind a VPN or an IP allow list, until the code is fixed.
3. Check the vendor site for a patched release. The record lists none, so do not assume one exists.
4. Rewrite the query in search-invoices.php so values are bound as parameters, never joined into the SQL text.
5. Give the application's database account only the rights it needs. It should not own the schema or read unrelated tables.
6. Review web server and database logs for the period since the public disclosure date of 2025-12-21.
7. If the application is not essential, retire it. Unmaintained code is a standing risk.

A prepared statement keeps the SQL text and the data apart. This pattern with PDO is the usual fix:

$stmt = $pdo->prepare('SELECT * FROM items WHERE id = :id');
$stmt->execute(['id' => $id]);

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.

Public disclosure does not equal confirmed exploitation. This CVE is not in the CISA KEV catalog. But when exploit details are public, scanners and curious visitors can find an exposed copy quickly, so the gap between disclosure and abuse can be short.

Small business applications of this kind are often installed once and then forgotten. That is the real risk: nobody owns the update, and no vendor patch may ever arrive.

If you build or maintain PHP code yourself, the lesson is cheap to apply. Treat every value from a request, cookie or header as hostile. Use prepared statements everywhere, validate types (an ID should be an integer), and run static analysis in your pipeline so the next concatenated query is caught in review. Reachability analysis helps on the dependency side by separating vulnerable code you call from vulnerable code that merely sits on disk.

For the owner of a small site, a practical order of work is: remove public access, confirm the data you hold, fix the query, then restore access. Keep a note of what you changed so the next reviewer does not have to rediscover it.

Quick check

Sources

• CVE-2025-14989 record on NVD
• CVE-2025-14989 on Gold

Last reviewed: 19 October 2026.