Pimcore Hotspotimage Deserialization Flaw Allows PHP Object Injection via Object-Store Column (CVE-2026-55220)

What happened

A GHSA advisory (GHSA-w23p-wrp7-ch38, CVE-2026-55220) discloses a PHP Object Injection vulnerability (CWE-502) in pimcore/pimcore, affecting all currently maintained releases including the latest v2026.1.4 and v12.3.8. The flaw is in Hotspotimage::getDataFromResource(), which falls back to Serialize::unserialize() when the stored *__hotspots object-store column isn't valid JSON. That wrapper defaults its allowed_classes parameter to true, meaning any object can be instantiated from the deserialized bytes. The same unrestricted-deserialize pattern is reported to affect the sibling ImageGallery, Block, and Video marshallers. The researcher demonstrates, on a real local Pimcore deployment, that writing crafted serialized bytes into the img__hotspots column and then reloading the object triggers a gadget chain (GuzzleHttp\Cookie\FileCookieJar::__destruct, from Pimcore's bundled guzzlehttp/guzzle 7.11.0) resulting in an attacker-controlled file write — a primitive the advisory says can extend to remote code execution via other bundled gadget chains.

Why it matters

This is the deserialization leg of an attack chain: exploitation requires an attacker to already have some means of writing arbitrary bytes into the *__hotspots store column (e.g., an SQL-write or object-store-write primitive). Once that write is possible, there is no class allowlist to stop it — the very next load of that DataObject (which happens routinely via admin grid/detail views, frontend rendering, API reads, or inheritance resolution) executes the payload. Any Pimcore deployment using Hotspotimage (advanced image) fields — and potentially ImageGallery, Block, or Video fields via the same fallback pattern — is exposed. A public PoC exists, so the barrier to weaponization by anyone who already has a write primitive against these environments is low.

What defenders should watch for now

• Inventory Pimcore instances and confirm whether DataObject classes use Hotspotimage, ImageGallery, Block, or Video fields.
• Audit for any other primitive that could let an attacker write to object-store columns (SQL injection, admin API abuse, import/sync pipelines) — this vulnerability is only reachable once such a write exists, so closing those paths reduces exploitability even before a patch lands.
• Watch for anomalous processes spawned by PHP-FPM/web server workers immediately after DataObject saves or loads, and for unexpected file writes originating from Pimcore application paths.
• Review database audit logs or web server logs for writes containing PHP serialized-object markers (e.g., strings beginning with O: followed by a class name length) landing in *__hotspots-suffixed columns.
• Monitor for use of gadget-chain-relevant classes already present via bundled dependencies (e.g., Guzzle cookie jar classes) appearing unexpectedly in application logs or error traces.
• Track the vendor's fix — the advisory proposes flipping Serialize::unserialize()'s default to allowed_classes => false, or having each caller pass an explicit allowlist — and apply it once released.

Developing intel

This is a same-day advisory disclosure with a demonstrated PoC but, as of publication, no confirmed CVSS score or public patch release noted in the advisory. Details may evolve as the vendor responds. Full technical writeup and PoC: GHSA-w23p-wrp7-ch38.