CVE-2026-71294 in Cotonti
Summary
by MITRE • 08/05/2026
Cotonti CMS's Comments plugin deserializes user-supplied data without restricting the classes that may be instantiated. In plugins/comments/controllers/actions/CreateAction.php, a `ci` POST parameter obtained via `cot_import('ci', 'P', 'TXT')` (trim-only sanitization) is passed to `unserialize(base64_decode($ci))` with no `allowed_classes` restriction, reachable by any member with write access to comments (the default `Auth_members => 'RW'` setting in plugins/comments/comments.setup.php). In plugins/comments/controllers/actions/EditAction.php, a `cb` parameter is similarly deserialized via `unserialize(base64_decode($this->comeback))` in prepareComeBack(), reachable by any member editing their own comment. Because unserialize() is called without allowed_classes, an attacker can construct a serialized PHP object of any class loaded by Cotonti (a PHP Object Injection primitive). This was demonstrated in practice using Cotonti's own MySQL_cache class: a crafted serialized MySQL_cache object, once deserialized and later garbage-collected, triggers its __destruct()->flush() chain, causing an attacker-controlled INSERT INTO cot_cache with attacker-chosen row values — confirming genuine POP-chain exploitation, with further impact (including potential RCE) contingent on other gadget chains available in a given Cotonti installation's loaded classes. A third sink in DeleteAction.php contains the identical unserialize() pattern but is gated behind an admin-only authorization check and is not reachable by ordinary members.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/05/2026
The vulnerability identified in Cotonti CMS's Comments plugin represents a critical PHP Object Injection flaw that stems from improper input validation and unsafe deserialization practices. This issue manifests across multiple controller actions within the comments module, creating multiple attack vectors for privilege escalation and potential remote code execution. The core problem arises from the lack of class restriction during the unserialize() operation, allowing attackers to instantiate arbitrary PHP objects with malicious payloads.
The technical implementation of this vulnerability occurs in three distinct locations within the comments plugin's controller actions. In CreateAction.php, the ci POST parameter undergoes only basic trimming sanitization through cot_import('ci', 'P', 'TXT') before being passed directly to unserialize(base64_decode($ci)) without any allowed_classes restriction. This pattern is replicated in EditAction.php where the cb parameter is similarly processed through prepareComeBack() method. Both scenarios are accessible to users with basic comment write permissions, making this vulnerability particularly dangerous as it requires minimal privileges to exploit. The default authorization setting of Auth_members => 'RW' in comments.setup.php ensures that any registered member can potentially leverage these attack vectors.
The exploitation mechanism leverages PHP's object serialization capabilities combined with the principle of PHP Object Pollution (POP) chains. Attackers can construct serialized objects using Cotonti's own classes, such as MySQL_cache, which when deserialized trigger their __destruct() methods during garbage collection. This creates a chain reaction where the malicious object's destructor executes arbitrary SQL operations through INSERT INTO cot_cache with attacker-controlled parameters. The demonstration of this exploitation confirms that the attack vector is not theoretical but has been successfully demonstrated in practice. The vulnerability classifies under CWE-502 as it involves deserialization of untrusted data without proper validation, and aligns with ATT&CK technique T1203 for Exploitation for Privilege Escalation.
The operational impact extends beyond simple data manipulation to potential remote code execution depending on the available gadget chains within the specific Cotonti installation. While the primary attack vectors are accessible to regular members, a third vulnerability exists in DeleteAction.php that requires administrative privileges but follows identical unsafe patterns. This dual nature of the vulnerability creates both a low-privilege attack surface and a high-impact administrative vector, making it particularly concerning for production environments. The fact that attackers can leverage existing classes within the CMS framework means they don't need to create custom exploit code, reducing the barrier to successful exploitation.
Mitigation strategies must address the fundamental deserialization patterns throughout the affected components. Immediate remediation requires implementing allowed_classes parameter in all unserialize() calls, explicitly restricting which classes may be instantiated during deserialization processes. Additionally, the authorization checks for the administrative DeleteAction.php functionality should be reviewed to ensure proper privilege validation. Input sanitization should be strengthened beyond simple trimming to include comprehensive validation of serialized data formats. The recommended solution involves modifying the vulnerable controller methods to either remove unsafe deserialization entirely or implement strict class whitelisting that explicitly defines which objects are permitted during the unserialization process, thereby preventing attackers from constructing malicious payloads using arbitrary system classes.
The vulnerability demonstrates a classic security anti-pattern where legacy code practices fail to account for modern attack vectors. The CMS's architecture allows user-supplied data to flow directly into deserialization functions without proper sanitization or validation, creating a pathway for attackers to leverage the application's own class loading mechanisms against it. This pattern represents a fundamental architectural weakness that requires comprehensive review and remediation across all components that handle serialized data inputs, particularly in modules where user-generated content is processed and stored.