CVE-2025-4746: High SQL Injection in Campcodes Sales and Inventory

CVE-2025-4746 is a high severity SQL injection flaw (CVSS 7.3) in Campcodes Sales and Inventory System 1.0. The pr_id input handled by /pages/purchase_delete.php reaches a database query unsafely, and the record says it can be reached remotely. No fixed version is confirmed in the record, so check the vendor and cut exposure now.

What's affected

The record names Campcodes Sales and Inventory System 1.0. The weak spot is the file /pages/purchase_delete.php and its pr_id argument. The record also states that an exploit has been disclosed to the public. It does not say the flaw is exploited in the wild, and the CISA Known Exploited Vulnerabilities list does not include it.

The CVSS vector in the record lists no privileges required, so treat the page as reachable by anyone who can reach the site.

I could not confirm a fixed version or a vendor patch. The vendor site is listed as a reference in the record, so check it and any release notes before you decide the product is safe to keep running.

How to check if you're exposed

Start by finding out whether you run this product at all. Look on your web servers for the file named in the record:

find /var/www -name "purchase_delete.php" 2>/dev/null

If the path matches /pages/purchase_delete.php, you have the affected code. Check the version in the application footer, the readme or the admin page, and compare it with 1.0.

Next, read the file and see how the pr_id value is used. If it is concatenated into a query string, the page is in the same state the record describes. If it already uses prepared statements, your copy may differ from the one that was reported.

Your web server logs can also help. Search for requests to /pages/purchase_delete.php and look for unusual values in the pr_id field, long strings, or bursts of requests from one address. That will not prove safety, but it shows whether someone has been probing.

What to do now

1. List every place this application runs, including test and demo copies. Small PHP projects often end up forgotten on shared hosting.
2. Check the vendor site and release notes for a patched build. If none is confirmed, treat the product as unpatched.
3. Take the app off the public internet if you can, or restrict it by IP address or VPN until it is fixed.
4. If you must keep it online, change the query behind /pages/purchase_delete.php to a parameterized statement, or put a web application firewall rule in front of the pr_id field as a stopgap.
5. Make sure the database account used by the app has only the permissions it needs, and that it cannot read other databases.
6. Back up the database and review it for unexpected rows or new accounts.
7. Plan a replacement if the vendor does not ship a fix.

If you want a quick look at what your own projects pull in, the free in-browser dependency scan at https://gold.safeguard.sh/scan needs no setup. The Gold directory lets you look up other CVEs by id.

Why it matters

The root cause is the classic one. Input from a request is placed into an SQL statement as text, so characters that were meant to be data can change what the statement does. That is CWE-89, a form of the broader CWE-74 injection class. The fix in code is to use parameterized queries, so the database always treats the value as data.

Small PHP applications like this are often deployed exactly as shipped, so a flaw in the code is a flaw in every copy. One reported injection point is a reason to review the rest of the app, not just the field named in CVE-2025-4746. Even a medium or high score here can matter, because a database often holds personal data and login hashes.

Try it yourself

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

Quick check

Sources

• Gold page for CVE-2025-4746
• github.com (listed in the CVE record)
• vuldb.com (listed in the CVE record)
• vuldb.com (listed in the CVE record)
• vuldb.com (listed in the CVE record)

Last reviewed: 18 October 2026.