Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-09-14T17:17:47.610Z",
  "pubdate": "2026-09-14T17:17:47.610Z",
  "executiveSummary": "This vulnerability is an SQL injection flaw residing within the ClassDefinition handling mechanism of Pimcore. It is classified as an incomplete input validation vulnerability, where existing security controls fail to enforce full string sanitization for object identifiers.\nThe vulnerability allows an authenticated user with 'objects' permissions to manipulate database queries by injecting malicious SQL syntax through a crafted ClassDefinition UID.\nImpact includes unauthorized access to the application database, potential disclosure of sensitive information such as password hashes, and the capability to perform arbitrary data modification across the platform's tables.\nThe flaw affects Pimcore versions prior to 2026.1.5. Successful exploitation requires an authenticated session with specific object-related permissions, significantly lowering the barrier for internal attackers or compromised accounts to escalate their impact within the system.\nRemediation requires updating to the patched version, 2026.1.5, which implements comprehensive validation for identifier structures.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient input validation logic implemented within models/DataObject/ClassDefinition.php. While the application previously attempted to harden the system against malicious input by applying a start anchor to validation regular expressions, it failed to enforce an end-of-string anchor. Consequently, the validation logic only confirms that the beginning of the ClassDefinition UID matches expected patterns, allowing trailing malicious SQL payloads to bypass the filter.\nThe vulnerability is triggered when the application processes a data object containing a Block field. The underlying code path, specifically Block::load within models/DataObject/ClassDefinition/Data/Block.php, improperly handles the stored ClassDefinition ID. This ID is incorporated directly into an unquoted SQL table identifier in the database query string.\nThe attack flow proceeds as follows: First, an authenticated attacker with sufficient 'objects' permissions submits a malicious ClassDefinition UID that conforms to the loose validation prefix but includes trailing SQL injection sequences. When the system subsequently loads a data object associated with this manipulated definition, the application's database abstraction layer consumes the malicious UID. Because the ClassDefinition ID is injected into the query context without proper quoting or parameterization, the database engine interprets the injected syntax as part of the command structure rather than a literal string.\nThis allows the attacker to terminate the intended query and append arbitrary SQL commands, such as UNION SELECT statements or command sequences that modify table content. Given the architecture of the platform, this effectively grants the attacker control over the database execution context, leading to full data exposure or structural manipulation. The flaw is particularly dangerous because it represents an incomplete hardening effort, demonstrating a bypass of previous security patches that lacked strict enforcement. The vulnerability is present across all versions prior to 2026.1.5, where the deficient regex-based validation allows for the injection of characters that facilitate query manipulation."
}