Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
HIGH severity

Pimcore Admin Classic Bundle Vulnerable to SQL Injection in Translation Grid Date Filter via Unsanitized Property ParameterGHSA-h4ph-crvj-9h92

HIGHFix: pimcore/admin-ui-classic-bundle#1111

GHSA-h4ph-crvj-9h92 is a high-severity (CVSS 8.8) SQL Injection vulnerability in pimcore/admin-ui-classic-bundle. A fix is available for pimcore/admin-ui-classic-bundle — see the affected versions and patch details below.

Also known asCVE-2026-44741
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 8, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for GHSA-h4ph-crvj-9h92.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs41th percentile — riskier than 41% of all scored CVEsHighest risk
0.00%0.33%0.67%1.00%0.4%0.5%0.5%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-h4ph-crvj-9h92 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 384,534 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected
🐘pimcore/admin-ui-classic-bundle🐘pimcore/admin-ui-classic-bundle

Real-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

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:

$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:

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

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

--- 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));
                         }

Happy to submit this as a PR against a private fork if that is the preferred workflow.

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistpimcore/admin-ui-classic-bundle≥ 2.0.0-RC1&&< 2.3.62.3.6composer require pimcore/admin-ui-classic-bundle:^2.3.6
🐘Packagistpimcore/admin-ui-classic-bundleall versions1.7.18composer require pimcore/admin-ui-classic-bundle:^1.7.18

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pimcore/admin-ui-classic-bundle, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update pimcore/admin-ui-classic-bundle to 2.3.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h4ph-crvj-9h92 is resolved across your whole dependency graph.

  3. Workarounds

    Until you can upgrade, make sure every query built from user input uses parameterised statements or a prepared-statement API rather than string concatenation, and reduce the database account's privileges so an injected query cannot read or alter data beyond what the feature needs.

Frequently Asked Questions

# 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) - **Endp
O3 Security · Impact-Aware SCA

Is GHSA-h4ph-crvj-9h92 in your dependencies?

Find it across Packagist, including transitive dependencies.

Pimcore Admin Classic Bundle Vulnerable to SQL…