Which versions of Concrete CMS are affected by CVE-2026-10721?

Concrete CMS versions below 9.5.2 contain a high-severity PHP object injection vulnerability (CVSS 8.4) affecting Permission, Cache, and Search components.. A patch is available.

How to fix or mitigate CVE-2026-10721?

Within 24 hours: Inventory all Concrete CMS deployments and document current versions. Within 7 days: Upgrade to Concrete CMS version 9.5.2 or later once available; strengthen database access controls and restrict write privileges to essential administrators only. Within 30 days: Verify completion of upgrades across all instances and audit database access logs for unauthorized modifications.

Concrete CMS CVE-2026-10721

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

CVE-2026-10721 has a CVSS 4.0 base score of 8.4 (High). CVSS vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/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-35994 HIGH

Deserialization of Untrusted Data (CWE-502)

2026-06-10 ff5b8ace-8b95-4078-9743-eac1ca5451de

GHSA-g82f-9pw7-773w

PHP Deserialization

8.4

CVSS 4.0 · Vendor: ff5b8ace-8b95-4078-9743-eac1ca5451de

Severity by source

Vendor (ff5b8ace-8b95-4078-9743-eac1ca5451de) PRIMARY

8.4 HIGH

CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/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

Primary rating from Vendor (ff5b8ace-8b95-4078-9743-eac1ca5451de) · only source for this CVE.

CVSS VectorVendor: ff5b8ace-8b95-4078-9743-eac1ca5451de

CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/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

Attack Vector

Local

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jun 10, 2026 - 08:30 vuln.today

DescriptionCVE.org

Concrete CMS below 9.5.2 is vulnerable to PHP Object Injection via unserialize() calls in the in Permission, Cache, and Search components. An unauthenticated attacker may trigger arbitrary PHP object instantiation if a malicious serialized payload has been placed in the database. Thanks XananasX7 for reporting.

AnalysisAI

PHP Object Injection in Concrete CMS versions below 9.5.2 allows arbitrary PHP object instantiation through unsafe unserialize() calls in the Permission, Cache, and Search components. The flaw is triggered when a malicious serialized payload has already been written to the database, meaning the unauthenticated trigger depends on a prior write primitive existing in the deployment. No public exploit identified at time of analysis, and CVSS 4.0 base scores it 8.4 with high confidentiality, integrity, and availability impact.

Technical ContextAI

Concrete CMS is a PHP-based open-source content management system. The root cause is CWE-502 (Deserialization of Untrusted Data): the Permission, Cache, and Search subsystems pass database-sourced strings into PHP's native unserialize() without validating that the input is structurally safe or originates from a trusted producer. Because PHP's unserialize() instantiates arbitrary classes and invokes magic methods such as __wakeup, __destruct, and __toString during reconstruction, an attacker who can control the serialized blob can drive a POP (property-oriented programming) gadget chain through whatever classes the Concrete CMS autoloader exposes, frequently leading to file write, SSRF, or RCE depending on the gadget surface. The advisory points to the 9.5.2 release notes as the fix boundary.

RemediationAI

Vendor-released patch: upgrade Concrete CMS to version 9.5.2 or later, which removes the unsafe unserialize() usage in the Permission, Cache, and Search components, per the release notes at https://documentation.concretecms.org/9-x/developers/introduction/version-history/952-release-notes. If immediate upgrade is not possible, restrict database write access to the application service account only and audit recent rows in the cache, permissions, and search index tables for entries beginning with PHP serialized markers such as 'O:' or 'a:' followed by class names that do not match expected application classes, removing or quarantining suspicious values; this carries the trade-off of potential cache or search index regeneration cost. Additionally restrict administrative access to the CMS using network ACLs or a WAF in front of /dashboard and disable any custom integrations that write user-influenced data into the affected tables, accepting that this reduces but does not eliminate exposure until 9.5.2 is applied.