Admin ui classic bundle: Pimcore Admin Classic Bundle Vulnerable to SQL Injection in Translation Grid Date Filter via Unsanitized Property Parameter (CVE-2026-44741)
# GitHub Security Advisory Draft — GM-369 ## Summary SQL injection in Pimcore's translation grid date filter — the user-supplied `property` field from the filter JSON is interpolated directly into a `UNIX_TIMESTAMP(DATE(FROM_UNIXTIME(...)))` SQL expression without parameterization or allowlist validation. ## Severity CVSS 3.1: 8.8 (High) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H ## Affected Component - **Package:** `pimcore/admin-ui-classic-bundle` - **File:** `src/Controller/Admin/TranslationController.php` - **Lines:** 565 (input), 569 (inadequate sanitization), 593 (injection point) - **Endpoint:** `POST /admin/translation/translations` ## Description The translation grid endpoint processes JSON filter parameters. When a filter has `type: "date"`, the `property` field is extracted and used to construct a SQL expression: ```php $fieldname = $filter[$propertyField]; // Line 565 — user input $fieldname = str_replace('--', '', $fieldname); // Line 569 — trivially bypassable $fieldname = $tableName . '.' . $fieldname; // Line 577 $fieldname = "UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))"; // Line 593 — injection ``` The `str_replace('--', '')` sanitization is trivially bypassable (use `/**/` comments or `----`). In non-language mode, `$fieldname` is concatenated directly into the SQL condition without quoting or parameterization. ## Impact Authenticated user with translations view permission can extract arbitrary database data via UNION-based or error-based SQL injection. Combined with GM-249 (unsafe unserialize), this enables an SQLi → deserialization → RCE chain. ## Proof of Concept ``` POST /admin/translation/translations filter=[{"property":"1))) UNION SELECT password FROM users WHERE ((1","type":"date","operator":"eq","value":"2026-01-01"}] ``` ## Suggested Fix Validate `$fieldname` against an allowlist of valid column names before SQL interpolation: ```php $allowedDateColumns = ['creationDate', 'modificationDate']; if (!in_array($fieldname, $allowedDateColumns, true)) { continue; } ``` ## References - CWE-89: SQL Injection - Related: CVE-2026-27461 (RLIKE injection in Dependency/Dao.php — different code path) --- ## Suggested Fix In `TranslationController.php`: (1) Add allowlist check for non-language fieldnames before processing. (2) Replace raw string interpolation `UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))` with `$db->quoteIdentifier($fieldname)` to prevent SQL injection in date filter expressions. ```diff --- a/src/Controller/Admin/TranslationController.php +++ b/src/Controller/Admin/TranslationController.php @@ -569,7 +569,15 @@ class TranslationController extends AdminAbstractController $fieldname = str_replace('--', '', $fieldname); if (!$languageMode && in_array($fieldname, $validLanguages) || $languageMode && !in_array($fieldname, $validLanguages)) { continue; } + // Allowlist non-language fieldnames to prevent SQL injection + $allowedNonLanguageFields = ['key', 'type', 'creationDate', 'modificationDate']; + if (!$languageMode && !in_array($fieldname, $allowedNonLanguageFields) && !in_array($fieldname, $validLanguages)) { + continue; + } + if (!$languageMode) { $fieldname = $tableName . '.' . $fieldname; } @@ -582,7 +590,7 @@ class TranslationController extends AdminAbstractController } elseif ($filter[$operatorField] == 'eq') { $operator = '='; - $fieldname = "UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))"; + // Use validated fieldname only — never interpolate raw user input into SQL functions + $fieldname = sprintf('UNIX_TIMESTAMP(DATE(FROM_UNIXTIME(%s)))', $db->quoteIdentifier($fieldname)); } ``` --- ## Proposed Fix ```diff --- a/src/Controller/Admin/TranslationController.php +++ b/src/Controller/Admin/TranslationController.php @@ -569,7 +569,15 @@ class TranslationController extends AdminAbstractController $fieldname = str_replace('--', '', $fieldname); if (!$languageMode && in_array($fieldname, $validLanguages) || $languageMode && !in_array($fieldname, $validLanguages)) { continue; } + // Allowlist non-language fieldnames to prevent SQL injection + $allowedNonLanguageFields = ['key', 'type', 'creationDate', 'modificationDate']; + if (!$languageMode && !in_array($fieldname, $allowedNonLanguageFields) && !in_array($fieldname, $validLanguages)) { + continue; + } + if (!$languageMode) { $fieldname = $tableName . '.' . $fieldname;
AI Analysis
Technical Summary
The vulnerability exists in the Pimcore admin-ui-classic-bundle, specifically in the TranslationController.php file at the /admin/translation/translations endpoint. When processing JSON filters of type 'date', the 'property' field is extracted from user input and directly concatenated into a SQL expression involving UNIX_TIMESTAMP and FROM_UNIXTIME functions without parameterization or proper allowlist validation. The trivial sanitization via str_replace('--', '') is easily bypassed. This allows an authenticated user with translations view permission to execute UNION-based or error-based SQL injection attacks. The recommended fix involves validating the 'property' field against an allowlist of valid column names and using the database quoteIdentifier function to safely include the field name in SQL expressions.
Potential Impact
An authenticated user with translations view permission can exploit this vulnerability to perform SQL injection attacks, potentially extracting arbitrary database data. The vulnerability has a CVSS 3.1 score of 8.8 (High) with high impact on confidentiality, integrity, and availability. Additionally, when combined with another vulnerability (GM-249), it can lead to a chain resulting in remote code execution.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The suggested fix is to implement an allowlist validation for the 'property' parameter against known valid column names before using it in SQL queries. Additionally, raw string interpolation should be replaced with safe quoting of identifiers using the database's quoteIdentifier method. Until an official patch is released, ensure that only trusted users have translations view permission and monitor for suspicious activity related to this endpoint.
Admin ui classic bundle: Pimcore Admin Classic Bundle Vulnerable to SQL Injection in Translation Grid Date Filter via Unsanitized Property Parameter (CVE-2026-44741)
Description
# GitHub Security Advisory Draft — GM-369 ## Summary SQL injection in Pimcore's translation grid date filter — the user-supplied `property` field from the filter JSON is interpolated directly into a `UNIX_TIMESTAMP(DATE(FROM_UNIXTIME(...)))` SQL expression without parameterization or allowlist validation. ## Severity CVSS 3.1: 8.8 (High) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H ## Affected Component - **Package:** `pimcore/admin-ui-classic-bundle` - **File:** `src/Controller/Admin/TranslationController.php` - **Lines:** 565 (input), 569 (inadequate sanitization), 593 (injection point) - **Endpoint:** `POST /admin/translation/translations` ## Description The translation grid endpoint processes JSON filter parameters. When a filter has `type: "date"`, the `property` field is extracted and used to construct a SQL expression: ```php $fieldname = $filter[$propertyField]; // Line 565 — user input $fieldname = str_replace('--', '', $fieldname); // Line 569 — trivially bypassable $fieldname = $tableName . '.' . $fieldname; // Line 577 $fieldname = "UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))"; // Line 593 — injection ``` The `str_replace('--', '')` sanitization is trivially bypassable (use `/**/` comments or `----`). In non-language mode, `$fieldname` is concatenated directly into the SQL condition without quoting or parameterization. ## Impact Authenticated user with translations view permission can extract arbitrary database data via UNION-based or error-based SQL injection. Combined with GM-249 (unsafe unserialize), this enables an SQLi → deserialization → RCE chain. ## Proof of Concept ``` POST /admin/translation/translations filter=[{"property":"1))) UNION SELECT password FROM users WHERE ((1","type":"date","operator":"eq","value":"2026-01-01"}] ``` ## Suggested Fix Validate `$fieldname` against an allowlist of valid column names before SQL interpolation: ```php $allowedDateColumns = ['creationDate', 'modificationDate']; if (!in_array($fieldname, $allowedDateColumns, true)) { continue; } ``` ## References - CWE-89: SQL Injection - Related: CVE-2026-27461 (RLIKE injection in Dependency/Dao.php — different code path) --- ## Suggested Fix In `TranslationController.php`: (1) Add allowlist check for non-language fieldnames before processing. (2) Replace raw string interpolation `UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))` with `$db->quoteIdentifier($fieldname)` to prevent SQL injection in date filter expressions. ```diff --- a/src/Controller/Admin/TranslationController.php +++ b/src/Controller/Admin/TranslationController.php @@ -569,7 +569,15 @@ class TranslationController extends AdminAbstractController $fieldname = str_replace('--', '', $fieldname); if (!$languageMode && in_array($fieldname, $validLanguages) || $languageMode && !in_array($fieldname, $validLanguages)) { continue; } + // Allowlist non-language fieldnames to prevent SQL injection + $allowedNonLanguageFields = ['key', 'type', 'creationDate', 'modificationDate']; + if (!$languageMode && !in_array($fieldname, $allowedNonLanguageFields) && !in_array($fieldname, $validLanguages)) { + continue; + } + if (!$languageMode) { $fieldname = $tableName . '.' . $fieldname; } @@ -582,7 +590,7 @@ class TranslationController extends AdminAbstractController } elseif ($filter[$operatorField] == 'eq') { $operator = '='; - $fieldname = "UNIX_TIMESTAMP(DATE(FROM_UNIXTIME({$fieldname})))"; + // Use validated fieldname only — never interpolate raw user input into SQL functions + $fieldname = sprintf('UNIX_TIMESTAMP(DATE(FROM_UNIXTIME(%s)))', $db->quoteIdentifier($fieldname)); } ``` --- ## Proposed Fix ```diff --- a/src/Controller/Admin/TranslationController.php +++ b/src/Controller/Admin/TranslationController.php @@ -569,7 +569,15 @@ class TranslationController extends AdminAbstractController $fieldname = str_replace('--', '', $fieldname); if (!$languageMode && in_array($fieldname, $validLanguages) || $languageMode && !in_array($fieldname, $validLanguages)) { continue; } + // Allowlist non-language fieldnames to prevent SQL injection + $allowedNonLanguageFields = ['key', 'type', 'creationDate', 'modificationDate']; + if (!$languageMode && !in_array($fieldname, $allowedNonLanguageFields) && !in_array($fieldname, $validLanguages)) { + continue; + } + if (!$languageMode) { $fieldname = $tableName . '.' . $fieldname;
CVSS v3.1
Score 8.8high
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability exists in the Pimcore admin-ui-classic-bundle, specifically in the TranslationController.php file at the /admin/translation/translations endpoint. When processing JSON filters of type 'date', the 'property' field is extracted from user input and directly concatenated into a SQL expression involving UNIX_TIMESTAMP and FROM_UNIXTIME functions without parameterization or proper allowlist validation. The trivial sanitization via str_replace('--', '') is easily bypassed. This allows an authenticated user with translations view permission to execute UNION-based or error-based SQL injection attacks. The recommended fix involves validating the 'property' field against an allowlist of valid column names and using the database quoteIdentifier function to safely include the field name in SQL expressions.
Potential Impact
An authenticated user with translations view permission can exploit this vulnerability to perform SQL injection attacks, potentially extracting arbitrary database data. The vulnerability has a CVSS 3.1 score of 8.8 (High) with high impact on confidentiality, integrity, and availability. Additionally, when combined with another vulnerability (GM-249), it can lead to a chain resulting in remote code execution.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The suggested fix is to implement an allowlist validation for the 'property' parameter against known valid column names before using it in SQL queries. Additionally, raw string interpolation should be replaced with safe quoting of identifiers using the database's quoteIdentifier method. Until an official patch is released, ensure that only trusted users have translations view permission and monitor for suspicious activity related to this endpoint.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-h4ph-crvj-9h92
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-44741"]
- Ecosystems
- ["Packagist"]
- Database Specific Severity
- HIGH
- Cvss Version
- 3.1
Threat ID: 6a520eb968715ace438f561f
Added to database: 07/11/2026, 09:36:57 UTC
Last enriched: 07/11/2026, 09:52:07 UTC
Last updated: 07/31/2026, 12:27:30 UTC
Views: 18
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.