CVE-2026-45162: Pimcore RCE Vulnerability

CVE-2026-45162 Overview

CVE-2026-45162 is an insecure deserialization vulnerability in Pimcore, an open source Data and Experience Management Platform. Multiple code paths call PHP's unserialize() on data sourced from database columns and filesystem files without applying the allowed_classes restriction. An attacker who controls a serialized data source can trigger PHP object injection and achieve remote code execution through gadget chains. Affected code paths include lib/Tool/Authentication.php, models/Site/Dao.php, models/DataObject/ClassDefinition/CustomLayout/Dao.php, models/Tool/TmpStore/Dao.php, models/Asset/WebDAV/Service.php, and admin-ui-classic-bundle/src/Helper/Dashboard.php. The issue is fixed in Pimcore 11.5.17 (LTS) and 12.3.7.

Critical Impact
Successful exploitation enables remote code execution through PHP object injection, resulting in full compromise of confidentiality, integrity, and availability of the Pimcore application host.

Affected Products

Pimcore versions prior to 11.5.17 (LTS)
Pimcore 12.x versions prior to 12.3.7
Pimcore admin-ui-classic-bundle component using Helper/Dashboard.php

Discovery Timeline

2026-07-17 - CVE-2026-45162 published to NVD
2026-07-22 - Last updated in NVD database

Technical Details for CVE-2026-45162

Vulnerability Analysis

The vulnerability is classified as insecure deserialization [CWE-502]. Pimcore invokes PHP's unserialize() function against attacker-influenceable inputs without restricting which classes may be instantiated. When PHP deserializes a crafted payload, it can construct arbitrary application objects and invoke magic methods such as __wakeup(), __destruct(), or __toString(). Attackers chain these magic methods with existing application classes to form a POP (Property-Oriented Programming) gadget chain that culminates in code execution. The vulnerable sinks span authentication token handling, site configuration retrieval, class definition custom layouts, temporary store lookups, WebDAV delete logs, and dashboard helper state.

Root Cause

Each affected sink calls unserialize($data) without passing the allowed_classes option introduced in PHP 7. Without this option, every class autoloadable by Composer becomes a candidate gadget. The centralized helper lib/Tool/Serialize.php also lacked a class allowlist, so callers inherited unsafe defaults across the codebase.

Attack Vector

Exploitation requires the attacker to control the serialized data at rest. Viable primitives include writing to database rows consumed by the affected DAO classes, planting files consumed by the WebDAV delete log at self::getDeleteLogFile(), or influencing TmpStore records. Because the attack traverses stored serialized data, high privileges or a chained write primitive are typically needed, but successful deserialization then executes in the Pimcore application context.

php

// Patch: lib/Tool/Serialize.php - central helper now enforces allowed_classes
         return serialize($data);
     }
 
-    public static function unserialize(?string $data = null): mixed
+    public static function unserialize(?string $data = null, array|bool $allowedClasses = true): mixed
     {
-        if ($data) {
-            $data = unserialize($data);
+        if ($data === null || $data === '') {
+            return $data;
         }
 
-        return $data;
+        return unserialize($data, [
+            'allowed_classes' => $allowedClasses,
+        ]);
     }

Source: Pimcore commit 4788bf3

php

// Patch: models/Asset/WebDAV/Service.php - restricts deserialization to Asset class
     {
         $log = [];
         if (file_exists(self::getDeleteLogFile())) {
-            $log = unserialize(file_get_contents(self::getDeleteLogFile()));
+            $raw = file_get_contents(self::getDeleteLogFile());
+            if (is_string($raw)) {
+                $log = unserialize($raw, ['allowed_classes' => [Asset::class]]);
+            }
+
             if (!is_array($log)) {
                 $log = [];
             } else {

Source: Pimcore commit 4788bf3

Detection Methods for CVE-2026-45162

Indicators of Compromise

Unexpected PHP worker processes spawning shells, curl, wget, or outbound network connections from the Pimcore web root.
Serialized payloads beginning with O: (object markers) present in the tmp_store table, site configuration rows, or the WebDAV delete log file.
Modified or newly created files in var/, public/var/, or bundle directories that do not correspond to a known deployment.
Web server error logs referencing __wakeup, __destruct, or autoload failures for unusual class names.

Detection Strategies

Inventory Pimcore installations and compare the deployed version against 11.5.17 and 12.3.7.
Hunt for calls to unserialize() in custom bundles and enforce the allowed_classes parameter during code review.
Monitor database write access to tables consumed by affected DAOs, particularly tmp_store, sites, and custom_layouts.

Monitoring Recommendations

Alert on PHP-FPM or Apache child processes executing shell interpreters, package managers, or reverse shell utilities.
Enable file integrity monitoring on Pimcore var/, config/, and WebDAV log locations to detect tampering with serialized state.
Forward web application and PHP error logs to a centralized analytics platform for anomaly review.

How to Mitigate CVE-2026-45162

Immediate Actions Required

Upgrade Pimcore to 11.5.17 (LTS) or 12.3.7 without delay.
Audit database rows and filesystem artifacts consumed by the affected sinks for unexpected serialized objects and purge them if found.
Restrict administrative access to Pimcore backends and rotate credentials for accounts with write access to affected tables.

Patch Information

Pimcore released fixes in v12.3.7 and the corresponding 11.5.17 LTS build. The changes are tracked in pull request #19119 and the GHSA-36fc-7wjg-mfvj advisory. The patch centralizes unserialize() calls through Pimcore\Tool\Serialize::unserialize() and enforces allowed_classes at each sink.

Workarounds

If immediate patching is not feasible, apply the upstream diff from commit 4788bf3 to constrain allowed_classes at every vulnerable sink.
Place the Pimcore admin interface behind a VPN or IP allowlist to reduce exposure of authenticated endpoints that touch serialized state.
Enforce least privilege on the database user backing Pimcore so that write access is limited to the application account only.

bash

# Verify installed Pimcore version and upgrade via Composer
composer show pimcore/pimcore | grep versions
composer require pimcore/pimcore:^12.3.7 --with-all-dependencies
# For LTS deployments
composer require pimcore/pimcore:^11.5.17 --with-all-dependencies
bin/console cache:clear --env=prod