Pimcore has Unsafe PHP Deserialization in Multiple Locations Without allowed_classes Restriction (CVE-2026-45162)
# 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. ```php // 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
AI Analysis
Technical Summary
Pimcore versions <11.5.17 and >=2026.1.0 <2026.1.3 contain multiple unsafe PHP unserialize() calls in core files that deserialize data from database or filesystem sources without using the allowed_classes parameter. This allows an attacker who can write to these data sources (e.g., via SQL injection or file write vulnerabilities) to inject serialized PHP gadget chains that execute arbitrary code upon deserialization. The affected files include Authentication.php, Site/Dao.php, ClassDefinition/CustomLayout/Dao.php, TmpStore/Dao.php, Asset/WebDAV/Service.php, and admin-ui-classic-bundle Dashboard.php. The vulnerability is related to CWE-502 (Deserialization of Untrusted Data) and can lead to remote code execution by leveraging gadget chains in Pimcore's dependencies such as Guzzle, Symfony, Monolog, and Doctrine. The advisory recommends adding the allowed_classes parameter to all unserialize() calls or migrating to JSON serialization for safer data handling. No official patch is currently linked; patch status is not yet confirmed.
Potential Impact
Successful exploitation allows an attacker with write access to certain database tables or filesystem files to inject malicious serialized PHP objects. When Pimcore unserializes this data without class restrictions, it can trigger PHP object injection leading to remote code execution with the privileges of the web server process. This can compromise confidentiality, integrity, and availability of the affected system. The vulnerability has a high severity rating (CVSS 3.1 score 8.0) due to network attack vector, high privileges required, no user interaction, and complete impact on confidentiality, integrity, and availability.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The advisory suggests adding the allowed_classes parameter to all unserialize() calls to restrict object instantiation, e.g., using ['allowed_classes' => false] when no objects are needed. Alternatively, migrating serialization to JSON for data that does not require object preservation is recommended. Until an official patch is released, review and harden access controls to prevent unauthorized writes to the affected data sources (database tables and filesystem files).
Pimcore has Unsafe PHP Deserialization in Multiple Locations Without allowed_classes Restriction (CVE-2026-45162)
Description
# 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. ```php // 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
CVSS v3.1
Score 8.0high
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Pimcore versions <11.5.17 and >=2026.1.0 <2026.1.3 contain multiple unsafe PHP unserialize() calls in core files that deserialize data from database or filesystem sources without using the allowed_classes parameter. This allows an attacker who can write to these data sources (e.g., via SQL injection or file write vulnerabilities) to inject serialized PHP gadget chains that execute arbitrary code upon deserialization. The affected files include Authentication.php, Site/Dao.php, ClassDefinition/CustomLayout/Dao.php, TmpStore/Dao.php, Asset/WebDAV/Service.php, and admin-ui-classic-bundle Dashboard.php. The vulnerability is related to CWE-502 (Deserialization of Untrusted Data) and can lead to remote code execution by leveraging gadget chains in Pimcore's dependencies such as Guzzle, Symfony, Monolog, and Doctrine. The advisory recommends adding the allowed_classes parameter to all unserialize() calls or migrating to JSON serialization for safer data handling. No official patch is currently linked; patch status is not yet confirmed.
Potential Impact
Successful exploitation allows an attacker with write access to certain database tables or filesystem files to inject malicious serialized PHP objects. When Pimcore unserializes this data without class restrictions, it can trigger PHP object injection leading to remote code execution with the privileges of the web server process. This can compromise confidentiality, integrity, and availability of the affected system. The vulnerability has a high severity rating (CVSS 3.1 score 8.0) due to network attack vector, high privileges required, no user interaction, and complete impact on confidentiality, integrity, and availability.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The advisory suggests adding the allowed_classes parameter to all unserialize() calls to restrict object instantiation, e.g., using ['allowed_classes' => false] when no objects are needed. Alternatively, migrating serialization to JSON for data that does not require object preservation is recommended. Until an official patch is released, review and harden access controls to prevent unauthorized writes to the affected data sources (database tables and filesystem files).
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-36fc-7wjg-mfvj
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-45162"]
- Ecosystems
- ["Packagist"]
- Database Specific Severity
- HIGH
- Cvss Version
- 3.1
Threat ID: 6a520eb868715ace438f560d
Added to database: 07/11/2026, 09:36:56 UTC
Last enriched: 07/11/2026, 09:51:54 UTC
Last updated: 07/31/2026, 19:22:59 UTC
Views: 35
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.