CVE-2026-0591 is a SQL injection flaw in Online Product Reservation System 1.0 from code-projects, in /app/checkout/update.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: Online Product Reservation System, version 1.0, from code-projects.
- Component: /app/checkout/update.php, parameter id and qty.
- 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 "*update.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 update.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 update.php so id and qty 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 update.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.
The cart update handler takes an item ID and a quantity. Quantity fields look harmless because they are meant to be numbers, but a server that does not enforce the type will accept text, and that text can end up inside the SQL. Casting to an integer and binding the value both help; binding is the one that fixes the class.
Quick check
Is there a patch for CVE-2026-0591?
None is listed in the CVE record. Check code-projects for a newer release, and if there is none, fix the query yourself or stop running the app.
Is a numeric field safe from injection?
Only if the server enforces the type. The browser does not. Bind the value as a parameter and cast it to an integer in PHP before it reaches the query.
Sources
Last reviewed: 19 October 2026.
