CVE-2026-55634: Pimcore Vulnerable to Remote Code Execution via DataObject Class-Definition Field Name

Should you act?

Critical, preconditions apply

Severe if exploited, but exploitation needs conditions that may not apply to you. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• Not in CISA KEV, but CISA’s SSVC assessment records a public proof-of-concept, so attack code exists.
• EPSS 0.7%, percentile 50: FIRST’s model estimates a 0.7% chance of exploitation activity in the next 30 days, higher than 50% of all scored CVEs (moderate). EPSS is a probability, not a verdict.
• Needs an account (low (any account)). Exposure depends on who can log in.
• Only applies if your dependency tree includes pimcore/pimcore (Composer (PHP)) <= 12.3.9, fixed in 12.3.10; pimcore/pimcore (Composer (PHP)) >= 2026.1.0, <= 2026.1.5, fixed in 2026.1.6. Check your lockfile, including transitive dependencies.

What it is

Pimcore is an Open Source Data & Experience Management Platform. Prior to 11.5.19, 12.3.10, and 2026.1.6, the class-definition import endpoint /pimcore-studio/api/class/definition/configuration-view/detail/{id}/import accepts a DataObject field name that is emitted without an identifier allowlist by lib/DataObject/ClassBuilder/FieldDefinitionPropertiesBuilder.php into generated PHP properties and by models/DataObject/ClassDefinition/Helper/Dao.php into ALTER TABLE identifiers. An authenticated user with the objects permission can inject PHP syntax into the generated DataObject class, causing attacker-controlled code in generated var/classes/DataObject/.php files to run when an object of that class is instantiated, and can also inject SQL identifier content into schema-changing statements. The central models/DataObject/ClassDefinition/Data.php::setName() validation did not reject semicolons, braces, backticks, spaces, or other non-identifier characters. This issue is fixed in versions 11.5.19, 12.3.10, and 2026.1.6.

From the GitHub advisory

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

Weakness type: CWE-89, CWE-94.

Product: pimcore/pimcore (Composer (PHP)) · Assigned by: GitHub_M · Published: 2026-08-28

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Privileges required: low (any account)
• User interaction: none
• Scope: changed (can affect other components)

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation poc, automatable no, technical impact total.
• FIRST EPSS (model of 2026-10-21): 0.65% probability of exploitation activity in the next 30 days; percentile 50.

Timeline

• 2026-08-28 — CVE record last updated
• 2026-08-28 — CVE record published by GitHub_M
• 2026-08-28 — GitHub-reviewed advisory GHSA-9x44-4gxf-8c25 published (critical)

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vulnerability records

1. GitHub Advisory GHSA-9x44-4gxf-8c25 github.com
2. CVE.org record CVE-2026-55634 cve.org
3. NVD entry CVE-2026-55634 nvd.nist.gov

Other references from the CVE record and advisory

1. github.com github.com
2. github.com github.com
3. github.com github.com
4. github.com github.com
5. github.com github.com

Critical Composer (PHP) advisories · Today’s Security Digest