CVE-2026-0597 is a SQL injection flaw in Supplier Management System 1.0 from Campcodes, in /retailer/edit_profile.php. NVD scores it 6.3, medium severity, and the record says an exploit has been published. No fixed version is listed, so the fix is to correct the query in your copy or take the app offline.
What's affected
- Product: Supplier Management System, version 1.0, from Campcodes.
- Component: /retailer/edit_profile.php, parameter txtRetailerAddress.
- Fixed version: none listed in the CVE record or the public report. Check the vendor page for any newer release.
- Severity: CVSS 6.3, vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L. The vector lists low privileges required, so an account of some kind is assumed. - Exploitation: the record says exploit details are public. It is not on the CISA Known Exploited Vulnerabilities list.
How to check if you're exposed
This is source code you host, so first find out whether you run it.
find /var/www -type f -path "*edit_profile.php" 2>/dev/null
If the file exists and the site is reachable from the internet, treat it as exposed. Then search your access logs for requests to edit_profile.php.
What to do now
- Take the app off the public internet, or put it behind a VPN or an authenticating reverse proxy, until the query is fixed.
- If you keep running it, change the code in edit_profile.php so txtRetailerAddress reaches the database through a prepared statement (PDO or mysqli) instead of string concatenation.
- Run the database account for this app with only the privileges it needs. It should not own the schema or be able to read other databases.
- Search access logs for unusual requests to edit_profile.php and for database errors in the PHP log, then reset any passwords that may have been exposed.
Why it matters
The weakness is CWE-89 (improper neutralization of special elements in an SQL command), a child of CWE-74 (injection). The app builds a query by pasting request data straight into SQL text, so the database cannot tell data from instructions. The public report for this product family describes that exact pattern.
A retailer profile page lets a logged in retailer edit their own address, and the address field is the one the record names. In a multi-user system, the more worrying case is one retailer reading or changing the data of another retailer through a shared table, so check how your deployment separates accounts. The public report was a GitHub issue I could not retrieve, so this post relies on the CVE record.
Quick check
Is there a patch for CVE-2026-0597?
None is listed in the CVE record. Check Campcodes for a newer release, and if there is none, fix the query yourself or stop running the app.
Why look at account separation too?
A profile update that can be altered by request data may reach rows owned by other users. Check whether your data model keeps retailers apart at the query level.
Sources
Last reviewed: 19 October 2026.
