Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-28T20:18:29.627Z",
  "pubdate": "2026-08-28T20:18:29.627Z",
  "executiveSummary": "Pimcore is susceptible to a critical Remote Code Execution (RCE) and SQL injection vulnerability residing within the class-definition import functionality. The flaw originates from inadequate input validation and sanitization of DataObject field names processed during class definition imports. By leveraging an authenticated session with object-level permissions, an attacker can supply malicious input that is unsafely embedded into dynamically generated PHP files and database schema alteration statements.\nThe vulnerability allows for the injection of arbitrary PHP syntax, which is subsequently executed by the application whenever the compromised DataObject class is instantiated. Furthermore, the ability to inject SQL identifier content facilitates unauthorized database schema manipulations. This combination of vulnerabilities enables a low-privileged authenticated user to escalate privileges, gain full control over the application server, and compromise database integrity. The risk is classified as critical due to the potential for complete system takeover, remote code execution, and data exfiltration. The vulnerability impacts versions prior to 11.5.19, 12.3.10, and 2026.1.6.",
  "technicalDetails": "The vulnerability is primarily located in the class-definition import endpoint: /pimcore-studio/api/class/definition/configuration-view/detail/{id}/import. The flaw arises because the application fails to enforce an allowlist for DataObject field names, allowing for the injection of malicious characters and payloads. Specifically, the method models/DataObject/ClassDefinition/Data.php::setName() performs insufficient validation, failing to filter dangerous characters such as semicolons, braces, backticks, and whitespace.\nThe attack flow begins when an authenticated user sends a crafted import request to the specified endpoint. The malicious payload, embedded in the field name, is processed by lib/DataObject/ClassBuilder/FieldDefinitionPropertiesBuilder.php, which writes the input directly into the generated PHP class files stored in var/classes/DataObject/.php. Because these files are dynamically generated and subsequently included or executed by the Pimcore framework during object instantiation, the injected PHP syntax is evaluated by the server's PHP interpreter, resulting in arbitrary code execution (ACE).\nConcurrently, the input is passed to models/DataObject/ClassDefinition/Helper/Dao.php for use in SQL schema-altering statements. Because the input is not properly escaped or restricted to legitimate identifier formats, an attacker can perform SQL injection. This allows for the manipulation of table identifiers, potentially leading to unauthorized schema modifications, data destruction, or information leakage from the underlying database.\nThe exploitation process follows these steps: 1) The attacker gains access to a valid authenticated session with object permissions. 2) The attacker crafts a request to the class import API, including a field name containing PHP escape sequences (e.g., closing PHP tags, malicious system commands) or SQL structural syntax. 3) The backend receives the payload and writes it into the generated class file on the filesystem. 4) The attacker triggers the instantiation of the affected DataObject, forcing the application to load and execute the corrupted PHP file. 5) The injected payload executes with the privileges of the web server process, leading to full RCE and potential persistence via modified class definitions."
}