CVE-2025-47292: Cap Collectif RCE Vulnerability

CVE-2025-47292 Overview

CVE-2025-47292 is a critical insecure deserialization vulnerability affecting Cap Collectif, an online decision-making platform that integrates several collaborative tools. The vulnerability exists in the DebateAlternateArgumentsResolver component, which deserializes a Cursor object without restricting allowed classes. This flaw can be exploited by unauthenticated users to achieve Remote Code Execution (RCE) on affected systems.

Critical Impact

Unauthenticated attackers can exploit this insecure deserialization vulnerability to execute arbitrary code on vulnerable Cap Collectif instances, potentially leading to complete system compromise.

Affected Products

• Cap Collectif (versions prior to commit 812f2a7d271b76deab1175bdaf2be0b8102dd198)

Discovery Timeline

• 2025-05-14 - CVE-2025-47292 published to NVD
• 2025-05-16 - Last updated in NVD database

Technical Details for CVE-2025-47292

Vulnerability Analysis

This vulnerability is classified as CWE-502 (Deserialization of Untrusted Data). The root issue lies in the unsafe use of PHP's unserialize() function without properly restricting which classes can be instantiated during the deserialization process.

The DebateAlternateArgumentsResolver component accepts user-controlled cursor data through GraphQL queries. When processing pagination cursors, the application base64-decodes the cursor value and passes it directly to unserialize() without any class restrictions. This allows an attacker to craft a malicious serialized payload containing arbitrary PHP objects, which can trigger dangerous side effects during unserialization—a technique commonly known as PHP Object Injection.

Since this endpoint does not require authentication, any remote attacker with network access to the application can exploit this vulnerability to achieve code execution with the privileges of the web server process.

Root Cause

The vulnerability stems from the unsafe call to unserialize() in the decodeCursor() method within DebateAlternateArgumentsResolver.php. The original implementation did not specify the allowed_classes option, permitting instantiation of any available PHP class during deserialization. PHP's unserialize() function can invoke magic methods such as __wakeup(), __destruct(), and __toString() on deserialized objects, which attackers can chain together to achieve arbitrary code execution.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can craft a malicious base64-encoded serialized payload and submit it as a cursor parameter to the debate arguments GraphQL resolver. The payload would contain gadget chains that exploit autoloaded classes within the application or its dependencies to execute arbitrary commands.

The following patch demonstrates the fix applied to the vulnerable decodeCursor() function:

     private static function decodeCursor(?string $cursor): array
     {
         return $cursor
-            ? unserialize(base64_decode($cursor))
+            ? unserialize(base64_decode($cursor), ['allowed_classes' => false])
             : [
                 'for' => null,
                 'against' => null,

Source: GitHub Commit

A similar fix was applied in DefaultPatternGenerationStrategy.php:

                     $metadata = $this->cacheDir . '/translations/catalogue.' . $locale . '.php.meta'
                 )
             ) {
-                foreach (unserialize(file_get_contents($metadata)) as $resource) {
+                foreach (unserialize(file_get_contents($metadata), ['allowed_class' => false]) as $resource) {
                     $i18nCollection->addResource($resource);
                 }
             }

Source: GitHub Commit

Detection Methods for CVE-2025-47292

Indicators of Compromise

• Unusual base64-encoded payloads in GraphQL cursor parameters containing PHP serialized object signatures (e.g., O: prefix after decoding)
• Web server logs showing abnormal requests to debate-related GraphQL endpoints with large or suspicious cursor values
• Unexpected process spawning or file system modifications originating from the web server process
• Error logs containing PHP unserialization warnings or object instantiation errors for unexpected classes

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect and block serialized PHP object patterns in request parameters
• Deploy runtime application self-protection (RASP) solutions to monitor and alert on unserialize() calls with untrusted input
• Monitor GraphQL query logs for anomalous cursor parameter patterns or unusually large payloads
• Configure intrusion detection systems to alert on command execution or reverse shell indicators from web server processes

Monitoring Recommendations

• Enable detailed logging for all GraphQL API endpoints, particularly those handling pagination cursors
• Implement anomaly detection for web server process behavior, including network connections and child process creation
• Monitor file integrity for web application directories to detect unauthorized modifications
• Set up alerts for PHP error logs indicating deserialization failures or unexpected class instantiation attempts

How to Mitigate CVE-2025-47292

Immediate Actions Required

• Update Cap Collectif to a version that includes commit 812f2a7d271b76deab1175bdaf2be0b8102dd198 or later
• If immediate patching is not possible, consider temporarily restricting network access to the affected application
• Review web server logs for signs of exploitation attempts
• Audit other areas of the codebase for similar unsafe unserialize() calls without allowed_classes restrictions

Patch Information

The vulnerability has been fixed in commit 812f2a7d271b76deab1175bdaf2be0b8102dd198. The patch adds the allowed_classes => false option to all unserialize() calls, preventing instantiation of arbitrary PHP classes during deserialization. For detailed information, see the GitHub Security Advisory and the commit update.

Workarounds

• Deploy a Web Application Firewall with rules to filter requests containing serialized PHP object patterns
• Implement network segmentation to limit exposure of the Cap Collectif application to trusted networks only
• Consider using a reverse proxy to sanitize or reject GraphQL requests with suspicious cursor parameters
• Monitor and restrict outbound connections from the web server to detect and prevent reverse shell attempts

# Example WAF rule pattern to detect PHP serialized objects in requests
# Block requests containing base64-decoded PHP serialized object signatures
# Pattern matches: O:[0-9]+:" (PHP object serialization prefix)
SecRule ARGS "@rx (?:^|[^a-zA-Z0-9])O:[0-9]+:\"" "id:100001,phase:2,deny,status:403,msg:'Potential PHP Object Injection detected'"