CVE-2026-7888: Concrete CMS PHP Object Injection RCE Flaw

CVE-2026-7888 Overview

CVE-2026-7888 affects Concrete CMS versions below 9.5.2. The vulnerability allows PHP Object Injection through unserialize() calls in the Workflow, Form block, and File/Set components. These calls lack the allowed_classes restriction, permitting arbitrary PHP object instantiation. An attacker who places a malicious serialized payload in the database can trigger object instantiation without authentication at the trigger point. The flaw maps to [CWE-502: Deserialization of Untrusted Data].

Critical Impact

Successful exploitation enables arbitrary PHP object instantiation, which can lead to code execution, data tampering, or full compromise of the Concrete CMS instance.

Affected Products

• Concrete CMS versions below 9.5.2
• Concrete CMS Workflow component
• Concrete CMS Form block and File/Set components

Discovery Timeline

• Vulnerability independently reported by XananasX7 and Sanjorn Keeratirungsan (dizconnect)
• 2026-06-03 - CVE-2026-7888 published to NVD
• 2026-06-03 - Last updated in NVD database

Technical Details for CVE-2026-7888

Vulnerability Analysis

The vulnerability stems from unsafe use of PHP's unserialize() function across three Concrete CMS components: Workflow, Form block, and File/Set. PHP's unserialize() reconstructs objects from a serialized string and invokes magic methods such as __wakeup() and __destruct() during the process. When the second argument allowed_classes is omitted or set to true, the function instantiates any class available in the application. Attackers can chain existing classes into a POP (Property-Oriented Programming) gadget that leads to file writes, command execution, or authentication state changes. The bug is classified under [CWE-502].

Root Cause

The affected code paths call unserialize() on data retrieved from the database without restricting the classes that may be instantiated. Concrete CMS versions prior to 9.5.2 do not pass the ['allowed_classes' => false] option, so any serializable class in the autoloader scope can be hydrated.

Attack Vector

Exploitation requires that a malicious serialized payload first reaches the database. An attacker with high privileges, or any path that allows tainted data to land in the Workflow, Form block, or File/Set storage, can stage the payload. The subsequent unserialize() operation then triggers object instantiation when the affected component reads the record. The CVSS 4.0 vector indicates a local attack surface with high privileges required and no user interaction, with high impact on confidentiality, integrity, and availability.

No verified public proof-of-concept code is available. Refer to the ConcreteCMS Version 9.5 Release Notes for fix details.

Detection Methods for CVE-2026-7888

Indicators of Compromise

• Database rows in Workflow, Form block, or File/Set tables containing serialized strings beginning with O: followed by a class name not normally used by Concrete CMS.
• Unexpected PHP files written under the web root or application/files/ directory.
• PHP error log entries referencing __wakeup, __destruct, or autoloader failures for unfamiliar classes.

Detection Strategies

• Audit database tables associated with Workflow, Form block, and File/Set for serialized object payloads using pattern matching on O:\d+:".
• Review web server logs for administrative requests that immediately precede anomalous PHP process activity.
• Inspect file system changes within the Concrete CMS installation directory for new or modified PHP scripts.

Monitoring Recommendations

• Enable PHP error and access logging at sufficient verbosity to capture deserialization failures.
• Forward web server and application logs to a centralized analytics platform for correlation across requests, database changes, and process execution.
• Alert on outbound network connections initiated by the php-fpm or web server process to unrecognized destinations.

How to Mitigate CVE-2026-7888

Immediate Actions Required

• Upgrade Concrete CMS to version 9.5.2 or later, which adds the allowed_classes restriction to the affected unserialize() calls.
• Restrict administrative access to the Concrete CMS dashboard and rotate credentials for any account with elevated privileges.
• Review database contents in Workflow, Form block, and File/Set storage for unexpected serialized payloads and remove them.

Patch Information

Concrete CMS resolved this issue in version 9.5.2. The fix introduces the allowed_classes parameter to unserialize() calls in the Workflow, Form block, and File/Set components, preventing arbitrary class instantiation. See the ConcreteCMS Version 9.5 Release Notes for the complete fix list.

Workarounds

• Limit database write access so only the application service account can modify Concrete CMS tables.
• Place the Concrete CMS administrative interface behind network controls or VPN access to reduce exposure of high-privilege endpoints.
• Apply a Web Application Firewall rule set that blocks serialized PHP object patterns in request bodies submitted to administrative endpoints.

# Configuration example: verify installed version and upgrade via Composer
php concrete/bin/concrete5 c5:info | grep -i version
composer require concretecms/concretecms:^9.5.2