CVE-2023-7106 is a SQL injection flaw in code-projects E-Commerce Website 1.0, a small PHP sample application. NVD scores it 6.3 (Medium) because the attacker needs a low-privilege account. No fixed version is named in the record, so the practical answer is to retire the app or parameterize its queries.
What's affected
The record lists one product and one version: E-Commerce Website 1.0 from code-projects (the CPE vendor field reads fabian). The vulnerable spot is the file product_details.php, through the prod_id argument.
There is no fixed version in the record. A public write-up by the researcher exists in a GitHub repository, and the record says the exploit has been disclosed publicly and may be used. It is not listed in CISA's Known Exploited Vulnerabilities catalog, and I found no advisory stating that it is exploited in the wild.
Severity note: the description repeats the label critical, which comes from the VulDB entry (VDB-249001). The CVSS 3.1 vector in NVD is AV:N/AC:L/PR:L/UI:N with low impact on confidentiality, integrity and availability, which gives 6.3. Both numbers are worth knowing, and the score is what the title uses.
How to check if you're exposed
This is source code you host yourself, so the check is a look at your own deployment.
# find the vulnerable file and any copy of it
find . -name product_details.php
# see how prod_id reaches a query
grep -n "prod_id" product_details.php
If the value from the request is concatenated into a query string, you are exposed. If you only know the app by name, check your inventory for a code-projects E-Commerce Website 1.0 deployment. The free in-browser dependency scan at gold.safeguard.sh/scan will not see a hand-copied PHP app, so an inventory or a code search is the reliable route here.
What to do now
- Treat E-Commerce Website 1.0 as unpatched. The record names no fixed version and I could not confirm one from a vendor page, so do not assume a newer download is safe without checking.
- Do not run this code on a public server. Sample applications from source code sites are meant for learning, and they rarely get security updates.
- If you must keep it running, review every place the code builds a query from request data and switch those to parameterized queries (prepared statements).
- Give the database account the application uses the minimum rights it needs, and remove any admin or file rights it does not use.
- Put the application behind authentication or a network restriction while you work, and watch web server logs for unusual values in the affected parameter.
Why it matters
SQL injection is the classic result of building a database query by joining strings, so that a value the user supplied can change the meaning of the query instead of being treated as plain data. The weakness class is CWE-89. The durable fix is not a filter for bad characters. It is parameterized queries, where the query text and the values travel separately and the database never confuses one for the other.
Beyond the code fix, the account the application uses to talk to the database matters. An app that connects with broad rights turns a small bug into a large one. A narrowly scoped database user limits what a successful injection can read or change.
The record's vector shows that a login is needed (PR:L), which is why the score sits in the medium band. Many small shops give customers accounts, so that bar is low in practice.
Quick check
Is there a patch for CVE-2023-7106?
The record does not name a fixed version, and I could not confirm one from a vendor page. Check the code-projects download page and treat any unpatched copy as vulnerable.
Is CVE-2023-7106 exploited in the wild?
Not according to the record. The KEV flag is false. The record does say the exploit details were disclosed publicly.
Sources
Last reviewed: 19 October 2026.
