CVE-2025-7607: High SQL Injection in Simple Shopping Cart

CVE-2025-7607 is a high severity (CVSS 7.3) SQL injection in code-projects Simple Shopping Cart 1.0. The order_price parameter in /Customers/save_order.php reaches a database query without safe handling, and the CVSS vector lists network access with no login or user interaction. The record names no fixed version, so rewrite the query or take the app offline.

The description says the exploit has been disclosed to the public and may be used. The record does not flag this CVE as exploited in the wild, and it is not marked as a CISA Known Exploited Vulnerability. Public details still make it easy for others to try, so do not wait on that distinction.

What's affected

The record lists code-projects Simple Shopping Cart 1.0. The weakness is in /Customers/save_order.php, through the order_price parameter. The price of an order arrives as a parameter in a script that saves the order. Any value the browser sends, including a price, must be treated as untrusted input. A shopping cart application normally keeps customer accounts, orders and prices in one database.

I could not confirm a fixed version. The record lists none, and the vendor page is a general site, not a security advisory. Simple Shopping Cart appears to be distributed as a free downloadable sample project, so a patched release may never ship. Treat any copy you run as unpatched until you have changed the code yourself.

This is one of several SQL injection reports against the same product. The others in this batch are CVE-2025-7608, CVE-2025-7609. Each one names a different file, which is a strong hint that the same mistake is repeated across the code base. Fixing /Customers/save_order.php alone will not make the application safe.

Severity needs a note. The description calls the issue critical, which is the wording VulDB uses when it files these reports. The score in the record is CVSS 7.3, which is High, with a vector of network access, low complexity, no privileges, no user interaction and low impact on each of confidentiality, integrity and availability. This post uses the score. The public write-up linked from the record (see Sources) was readable when I checked. It describes the same weakness as the record, a request value used directly in a SQL query without cleaning or validation.

How to check if you're exposed

First find out whether you run this application at all. Search web roots and repositories for the file name and for the product name:

find / -name "save_order.php" -path "*php*" 2>/dev/null
grep -rIl "Simple Shopping Cart" /var/www 2>/dev/null

If the file exists, open it and look at how the order_price value reaches the database. A query assembled by joining strings is the problem. A prepared statement with bound parameters is not:

grep -n "mysqli_query\|mysql_query\|->query(" save_order.php

Then look at your web server access log for requests to the file. Unusual quote characters, SQL keywords or very long values in the parameter deserve a closer look:

grep "save_order.php" /var/log/apache2/access.log | grep -i "%27\|union\|sleep(" | head

A clean log does not prove safety, because logging may be off or rotated. A hit means you should treat the database as possibly read or changed.

Safeguard's free in-browser dependency scan covers third party packages. It will not flag this issue, which sits in the application's own query code, so use code review or a SAST tool for that part.

What to do now

1. Decide whether the application needs to run. If it is a demo, a training copy or an unused install, remove it.
2. If it must stay up, take it off the public internet or limit it by IP address or VPN until the code is fixed.
3. Replace string built queries in /Customers/save_order.php and in every other file that talks to the database with prepared statements. In PHP with mysqli the pattern looks like this:

$stmt = $conn->prepare("SELECT * FROM some_table WHERE some_column = ?");
$stmt->bind_param("s", $value);
$stmt->execute();

4. Give the database account the application uses only the rights it needs. It should not own the schema or reach other databases.
5. Review access logs and recent database changes for signs of misuse. If you find any, rotate the database password and any application credentials.
6. A web application firewall rule can reduce noise while you fix the code. It is a stopgap, not a fix.

Try it yourself

This walkthrough shows how a scan finds a flaw of this class and what the finding looks like.

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

Why it matters

CWE-89 is SQL injection, and CWE-74 is the wider class of injection, where input changes the meaning of a command that another component interprets. Here the cause is plain: the order_price value is placed into a SQL statement without being kept separate from the command. The database cannot tell data from instructions, so crafted input can change what the query does.

The damage depends on the query and the database account. It can range from leaking records to changing or deleting them. In small PHP projects, one account often has wide rights, which raises the stakes. The fix is not a longer blocklist. It is keeping data out of the command text, which prepared statements do by design.

Quick check

Sources

• CVE-2025-7607 on Gold
• Public write-up linked from the record

Last reviewed: 18 October 2026.