Which versions of Pimcore are affected by CVE-2026-5394?

A SQL injection vulnerability in Pimcore's DataObject configuration handling (CVE-2026-5394) allows authenticated administrative users to escalate their access into arbitrary database command…. A patch is available.

How to fix or mitigate CVE-2026-5394?

Within 24 hours, create an inventory of all Pimcore instances in your environment and their current versions, flagging systems managing sensitive or regulated data for priority. Within 7 days, apply the available patch to all Pimcore installations according to the vendor advisory and conduct a forensic review of admin account activity logs over the past 30 days for suspicious database operations or configuration changes. Within 30 days, implement or strengthen administrative access controls by restricting Pimcore admin credentials to only necessary personnel, enable comprehensive database query logging if not currently active, and perform a risk reassessment of all privileged access management policies.

Pimcore CVE-2026-5394

Q: What is the CVSS score of CVE-2026-5394?

CVE-2026-5394 has a CVSS 4.0 base score of 7.0 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-25909 HIGH

SQL Injection (CWE-89)

2026-04-27 Fluid Attacks

GHSA-c8g3-x47w-8q7p

GHSA-r2f4-ff2p-xc64

SQLi Pimcore

7.0

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

7.0 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

6.0 MEDIUM

Reachable over the network but only by an admin with class-definition import/save rights (PR:H); SQLi yields full DB read (C:H) with limited DDL-driven write/availability impact (I:L/A:L), no scope change.

3.1 AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L

4.0 AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 24, 2026 - 05:03 vuln.today

Analysis Generated

Jul 24, 2026 - 05:03 vuln.today

CVSS changed

Apr 27, 2026 - 20:22 NVD

7.0 (HIGH)

EUVD ID Assigned

Apr 27, 2026 - 20:00 euvd

EUVD-2026-25909

CVE Published

Apr 27, 2026 - 19:15 nvd

HIGH 7.0

DescriptionCVE.org

An authenticated administrative user who can import or save DataObject class definitions can inject attacker-controlled composite index metadata and trigger unintended SQL execution in the backend.

This issue affects pimcore: 12.3.3.

AnalysisAI

SQL injection in Pimcore's DataObject composite index handling lets an authenticated administrative user (PR:H) escalate configuration-management rights into arbitrary SQL execution by importing or saving a crafted class definition. The vulnerable flow accepts compositeIndices from imported JSON and concatenates index_key and, more reliably, index_columns verbatim into ALTER TABLE ... DROP/ADD INDEX statements run through Doctrine DBAL. There is no public exploit identified at time of analysis and EPSS is 0.01%, but the GHSA advisory and PR #19108 fully document the root cause, so exploitation is well understood.

Technical ContextAI

Pimcore is an open-source PHP data/experience management platform (PIM/DAM/CMS) built on Symfony and Doctrine DBAL. The root cause is CWE-89 (SQL injection): Service::importClassDefinitionFromJson() ingests compositeIndices from user-supplied JSON, ClassDefinition::setCompositeIndices() stores it without an allowlist (only rewriting ManyToOne relations to __id/__type, which is not a security control), and CompositeIndexTrait::updateCompositeIndices() interpolates the index key and columns directly into 'ALTER TABLE table DROP INDEX ...' and 'ADD INDEX key (columns)' DDL. Because index_columns is placed verbatim inside the ADD INDEX (...) clause, an attacker can append additional ALTER TABLE subclauses without needing stacked-query support. The fix (commit 6df625f) introduces assertValidIdentifier() enforcing /^[a-zA-Z][a-zA-Z0-9_-]{0,63}$/ and switches to db->quoteIdentifier() for the table, key, and each column. CPE cpe:2.3:a:pimcore:pimcore identifies the single affected product.

RemediationAI

Vendor-released patch: upgrade to Pimcore 12.3.7 (12.x), 11.5.17 (11.x), or 2026.1.3 (calendar line) - via composer require pimcore/pimcore to the fixed release. The fix (PR https://github.com/pimcore/pimcore/pull/19108, commit https://github.com/pimcore/pimcore/commit/6df625ff74015dc11f4bbe76170ce45bbd5dd61d) adds strict identifier validation and quoteIdentifier() calls, so no functional class-definition behavior is lost. Until patching, the practical compensating controls are to restrict which accounts hold the class-definition import/save permission and avoid importing DataObject class definitions from untrusted sources, since exploitation requires that administrative capability; monitor the database DDL/query logs for anomalous ALTER TABLE statements against object tables. There is no configuration flag to disable the feature cleanly without breaking legitimate class management, so tightening admin authorization and import provenance is the main trade-off-bearing mitigation. Advisory: https://github.com/pimcore/pimcore/security/advisories/GHSA-r2f4-ff2p-xc64