Summary
Pimcore: Insufficient Permission Check on Class Definition Creation Endpoint Allows Privilege Escalation
The Studio API class definition creation endpoint in pimcore/studio-backend-bundle is guarded by the objects permission instead of the classes permission, allowing any standard editor-level user to create class definitions without admin privileges. Class definition creation is a structural admin operation that generates new database tables and PHP class files on the server. Additionally, the API layer performs no format validation on the uid field before passing it to the model layer, relying solely on model-level validation that exists downstream in ClassDefinition::saveClassInternal().
Details
Issue 1, Incorrect permission guard on CreateController
studio-backend-bundle/src/Class/Controller/DefinitionConfiguration/CreateController.php:
#[IsGranted(UserPermissions::DATA_OBJECTS->value)]
The endpoint POST /pimcore-studio/api/class/definition/configuration-view/detail/create is protected by DATA_OBJECTS (the objects permission), which is a standard editor-level permission granted to content editors for creating and editing data objects. Class definition creation is a structural admin operation equivalent to schema modification, it creates new database tables and generates PHP class files on the server. This operation should require the classes permission, which is the permission Pimcore enforces for class definition management in the Classic Admin.
Any authenticated user with object editing rights can call this endpoint and create new class definitions, bypassing the intended admin-only restriction. The same user cannot perform this action through the Classic Admin UI, confirming the Studio API enforces a weaker permission check than the existing interface.
Correct guard:
#[IsGranted(UserPermissions::CLASSES->value)]
Issue 2, No UID format validation at the API layer
studio-backend-bundle/src/Class/MappedParameter/CreateClassDefinitionParameters.php:
public function __construct(
private string $name,
private string $uid
) {
if (trim($name) === '' || trim($uid) === '') {
throw new InvalidArgumentException('Class name and UID cannot be empty.');
}
}
Only an empty-string check is performed on uid at the API boundary before the value is passed to the model layer. While ClassDefinition::saveClassInternal() now validates the UID format via anchored regex, no equivalent validation exists in CreateClassDefinitionParameters. A malformed UID passes through the API layer without any format check and only fails deep in the model layer, returning an unformatted internal exception to the caller rather than a clean 400 API validation response, which can expose internal stack traces depending on server configuration.
Defense-in-depth requires validation at the API boundary consistent with the model layer. The same regex now applied in ClassDefinition.php should also be enforced here:
if (!preg_match('/^[a-zA-Z0-9][a-zA-Z0-9_]*$/', trim($this->uid))) {
throw new InvalidArgumentException(
sprintf('Invalid UID for class definition: %s', $this->uid)
);
}
Affected files in pimcore/studio-backend-bundle:
src/Class/Controller/DefinitionConfiguration/CreateController.phpsrc/Class/MappedParameter/CreateClassDefinitionParameters.php
Vulnerable endpoint:POST /pimcore-studio/api/class/definition/configuration-view/detail/create
PoC
Prerequisites:
- Pimcore 2026.1.x with Studio API enabled
- A user
editorwith only theobjectspermission and noclassespermission
Step 1, Authenticate as the editor user:
curl -s -c /tmp/cookies.txt -X POST \
"https://your-pimcore/pimcore-studio/api/login" \
-H "Content-Type: application/json" \
-d '{"username":"editor","password":"password"}'
Expected response:
{"message": "Login successful"}
Step 2, Confirm the user has no class management access in Classic Admin
Log into Classic Admin as editor. Verify the Classes menu is not visible and
the user cannot access Settings > Classes. This confirms the classes permission
is not granted to this user.
Step 3, Create a class definition via the Studio API despite lacking the classes permission:
curl -s -b /tmp/cookies.txt -X POST \
"https://your-pimcore/pimcore-studio/api/class/definition/configuration-view/detail/create" \
-H "Content-Type: application/json" \
-d '{"name":"UnauthorizedClass","uid":"testuid1"}'
Expected response (vulnerable):
{"id": "testuid1", "name": "UnauthorizedClass", ...}
The class definition is created successfully by a user with no classes permission.
The Studio API accepts the request where the Classic Admin would deny it entirely.
Expected response (patched):
{"status": 403, "detail": "Access denied."}
Impact
Any authenticated Pimcore user with the standard objects permission can create class definitions via the Studio API, bypassing the classes permission restriction enforced in the Classic Admin. This is a privilege escalation from editor level to
a capability that should be restricted to administrators. Class definition creation generates new database tables and PHP class files on the server, giving an unprivileged user the ability to modify the application schema, introduce malformed class structures, and trigger downstream processing outside their permission scope.
The missing API-layer UID validation compounds this by allowing malformed UIDs to reach the model layer, producing unhandled internal exceptions that may expose stack traces depending on server debug configuration.
- Authentication required from attacker: Yes - valid Pimcore session with
objectspermission required - Authentication required from victim: No - no victim action needed
- What is accessible: Full class definition creation capability including database table generation and PHP class file creation on the server
The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.
CVE-2026-55212 has a CVSS score of 7.1 (High). 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 (2026.1.6); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
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. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
pimcore/studio-backend-bundle to 2026.1.6 or later; pimcore/studio-backend-bundle to 2026.1.6 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-55212? CVE-2026-55212 is a high-severity improper input validation vulnerability in pimcore/studio-backend-bundle (composer), affecting versions < 2025.4.6. It is fixed in 2026.1.6. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
- How severe is CVE-2026-55212? CVE-2026-55212 has a CVSS score of 7.1 (High). 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.
- Which versions of pimcore/studio-backend-bundle are affected by CVE-2026-55212? pimcore/studio-backend-bundle (composer) versions < 2025.4.6 is affected.
- Is there a fix for CVE-2026-55212? Yes. CVE-2026-55212 is fixed in 2026.1.6. Upgrade to this version or later.
- Is CVE-2026-55212 exploitable, and should I be worried? Whether CVE-2026-55212 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
- What actually determines whether CVE-2026-55212 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.
- How do I fix CVE-2026-55212?
- Upgrade
pimcore/studio-backend-bundleto 2026.1.6 or later - Upgrade
pimcore/studio-backend-bundleto 2026.1.6 or later
- Upgrade