CVE-2026-55634

Pimcore Vulnerable to Remote Code Execution via DataObject Class-Definition Field Name

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.

Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access. Typical impact: data disclosure or modification.

CVE-2026-55634 has a CVSS score of 9.9 (Critical). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (12.3.10, 2026.1.6); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

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

1. What is CVE-2026-55634? CVE-2026-55634 is a critical-severity SQL injection vulnerability in pimcore/pimcore (composer), affecting versions <= 12.3.9. It is fixed in 12.3.10, 2026.1.6. Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access.
2. How severe is CVE-2026-55634? CVE-2026-55634 has a CVSS score of 9.9 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of pimcore/pimcore are affected by CVE-2026-55634? pimcore/pimcore (composer) versions <= 12.3.9 is affected.
4. Is there a fix for CVE-2026-55634? Yes. CVE-2026-55634 is fixed in 12.3.10, 2026.1.6. Upgrade to this version or later.
5. Is CVE-2026-55634 exploitable, and should I be worried? Whether CVE-2026-55634 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-55634 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-55634?
   • Upgrade pimcore/pimcore to 12.3.10 or later
   • Upgrade pimcore/pimcore to 2026.1.6 or later