CVE-2025-14877: High SQL Injection in Supplier Management System

CVE-2025-14877 covers a high severity SQL injection (CVSS 7.3) in Campcodes Supplier Management System 1.0, in /admin/add_retailer.php. The cmbAreaCode argument feeds a database query unsafely. No fixed version appears in the record. Take the app off the open internet and switch the query to bound parameters.

What's affected

The record names Campcodes Supplier Management System 1.0. The vulnerable file is /admin/add_retailer.php, and the argument involved is the cmbAreaCode argument.

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

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

Then open add_retailer.php and find where cmbAreaCode is read. If its value is joined into an SQL string, you have the flaw described here. If it is passed to a prepared statement as a bound value, that path is not affected by this class of bug.

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 add_retailer.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-18.
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

The weakness here is classed as CWE-89, SQL injection, under the broader CWE-74. The application treats request data as trusted query text. The scores are 'low' for each impact area, but that is a per request rating. A database often holds far more than one page needs, which is why least privilege on the database account is worth the effort.

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.

Try it yourself

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

Quick check

Sources

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

Last reviewed: 19 October 2026.