CVE-2026-55212

Pimcore is an Open Source Data & Experience Management Platform. Prior to 2025.4.6 and 2026.1.6, the Studio API class definition creation endpoint POST /pimcore-studio/api/class/definition/configuration-view/detail/create is guarded by the objects permission instead of the classes permission, allowing a standard editor-level user to create class definitions without admin privileges. Class definition creation generates new database tables and PHP class files on the server, and missing API-layer UID format validation allows malformed UIDs to reach model-layer validation and return internal exceptions. This issue is fixed in versions 2025.4.6 and 2026.1.6.

Pimcore is an Open Source Data & Experience Management Platform. Prior to 2025.4.6 and 2026.1.6, the Studio API class definition creation endpoint POST /pimcore-studio/api/class/definition/configuration-view/detail/create is guarded by the objects permission instead of the classes permission, allowing a standard editor-level user to create class definitions without admin privileges. Class definition creation generates new database tables and PHP class files on the server, and missing API-layer UID format validation allows malformed UIDs to reach model-layer validation and return internal exceptions. This issue is fixed in versions 2025.4.6 and 2026.1.6.

Summary

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.php
• src/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 editor with only the objects permission and no classes permission

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…

Pimcore is an Open Source Data & Experience Management Platform. Prior to 2025.4.6 and 2026.1.6, the Studio API class definition creation endpoint POST /pimcore-studio/api/class/definition/configuration-view/detail/create is guarded by the objects permission instead of the classes permission, allowing a standard editor-level user to create class definitions without admin privileges. Class definition creation generates new database tables and PHP class files on the server, and missing API-layer UID format validation allows malformed UIDs to reach model-layer validation and return internal exceptions. This issue is fixed in versions 2025.4.6 and 2026.1.6.

Pimcore is an Open Source Data & Experience Management Platform. Prior to 2025.4.6 and 2026.1.6, the Studio API class definition creation endpoint POST /pimcore-studio/api/class/definition/configuration-view/detail/create is guarded by the objects permission instead of the classes permission, allowing a standard editor-level user to create class definitions without admin privileges. Class definition creation generates new database tables and PHP class files on the server, and missing API-layer UID format validation allows malformed UIDs to reach model-layer validation and return internal exceptions. This issue is fixed in versions 2025.4.6 and 2026.1.6.

Summary

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.php
• src/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 editor with only the objects permission and no classes permission

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…