CVE-2026-55208

Pimcore: SQL Injection via Column Name in DateFilter allows authenticated user to extract arbitrary database data including admin password hashes

Published

2026-08-28

Modified

2026-08-28

EPSS percentile

34%

Aliases

GHSA-79cw-hfcc-7mw9

Sources

github-advisory

Summary

## Summary An authenticated user extracts the admin password hash and any other database content through a time-based blind SQL injection in the `DateFilter` column key parameter. The `POST /pimcore-studio/api/website-settings` endpoint (and 11 other listing endpoints) accepts a `columnFilters` array where the `key` field is interpolated directly into SQL with only manual backtick wrapping. The `DateFilter` uses fixed named parameters (`:minTime`, `:maxTime`), so the injected column name is not subject to PDO named parameter validation. An attacker breaks out of the backtick quoting with a backtick character and appends arbitrary SQL, including `SLEEP()` for time-based extraction and `IF()` subqueries for conditional data exfiltration. ## Vulnerability Details ### Exploitable: DateFilter with Fixed Named Parameters `src/Listing/Filter/DateFilter.php` lines 49-57 handle the `on` operator. The column key comes from user input and is placed in the SQL with manual backtick wrapping, while the named parameters are hardcoded as `:minTime` and `:maxTime`: ```php $key = $column->getKey(); // user-controlled, no validation $dateCondition = '`' . $key . '` ' . ' BETWEEN :minTime AND :maxTime'; $listing->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => ...]); ``` Because the named parameters are fixed strings, PDO accepts the binding regardless of what the column name contains. ### Same Pattern in Note FilterService `src/Note/Service/FilterService.php` lines 64-67: ```php $dateCondition = '`' . $filter[$propertyKey] . '` ' . ' BETWEEN :minTime AND :maxTime'; $list->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => $maxTime]); ``` ### No Validation on Column Key `src/MappedParameter/Filter/ColumnFilter.php` accepts any string as the `key` with zero validation or allowlisting. ### Why Backtick Wrapping is Not Escaping Manual backtick wrapping (`` '`' . $key . '`' ``) does not escape internal backtick characters. `quoteIdentifier()` doubles them, manual wrapping does not. A backtick in the key breaks out of the quoting and the `-- ` (double dash space) comments out the remainder of the query: **Input:** ``key = "id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- "`` **Produces:** ```sql (`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- ` BETWEEN :minTime AND :maxTime) ``` Everything after `-- ` is a SQL comment. The injected `SLEEP(3)` executes unconditionally. ### Contrast with Safe Patterns in the Same Codebase - `LogRepository.php` line 202: uses `$this->dbResolver->get()->quoteIdentifier()` (safe) - `ClassificationStore/Configuration/KeyRepository.php`: uses `ALLOWED_SORT_KEYS` allowlist (safe) ### Note on EqualsFilter/LikeFilter The `EqualsFilter` and `LikeFilter` have the same manual backtick wrapping, but they reuse the column name as the PDO named parameter (`:columnName`). PDO requires named parameters to match `[a-zA-Z0-9_]`, so injection characters cause a parameter binding error before SQL execution. These filters are not exploitable through this vector. The DateFilter is exploitable because it uses independent fixed parameter names. ## Steps to Reproduce Tested on Pimcore 12.x (2026.x branch, latest commit `82f9ff6`), Docker, PHP 8.4, MariaDB 10.11. ### Step 1: Baseline request (no injection) ```http POST /pimcore-studio/api/website-settings HTTP/1.1 Host: localhost:8095 Content-Type: application/json Cookie: PHPSESSID= {"page":1,"pageSize":10} ``` **Response:** `HTTP/1.1 200 OK` -- `totalItems: 1` -- **0.07 seconds** ### Step 2: Unconditional SLEEP(3) injection ```http POST /pimcore-studio/api/website-settings HTTP/1.1 Host: localhost:8095 Content-Type: application/json Cookie: PHPSESSID= {"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND SLEEP(

Affected packages

Remediation: Upgrade to 2025.4.6 or later.

References

• https://github.com/advisories/GHSA-79cw-hfcc-7mw9