CVE-2024-28861: Symfony 1 RCE Vulnerability

CVE-2024-28861 Overview

CVE-2024-28861 is a critical insecure deserialization vulnerability affecting Symfony 1, a community-driven fork of the 1.x branch of the Symfony PHP framework. The vulnerability exists in the sfNamespacedParameterHolder class, where dangerous deserialization creates a gadget chain that enables remote code execution when a developer deserializes user input within their project.

Critical Impact

Attackers can achieve remote code execution by exploiting the insecure deserialization vulnerability in Symfony 1 applications that deserialize untrusted user input, potentially leading to complete system compromise.

Affected Products

• FriendsOfSymfony1 Symfony1 versions 1.1.0 through 1.5.18
• Applications using sfNamespacedParameterHolder or sfParameterHolder classes with user-controlled serialized data
• PHP web applications built on the Symfony 1 framework that deserialize untrusted input

Discovery Timeline

• 2024-03-22 - CVE CVE-2024-28861 published to NVD
• 2025-12-05 - Last updated in NVD database

Technical Details for CVE-2024-28861

Vulnerability Analysis

This vulnerability (CWE-502: Deserialization of Untrusted Data) resides in the __unserialize() magic method implementations within both sfParameterHolder and sfNamespacedParameterHolder classes. The vulnerable code fails to validate the type and structure of deserialized data before processing it, creating a gadget chain that attackers can exploit for remote code execution.

When PHP deserializes untrusted data into these classes, an attacker can craft malicious serialized payloads that, upon deserialization, trigger the execution of arbitrary code. This is a classic PHP object injection scenario where the framework's internal classes can be weaponized as part of a POP (Property-Oriented Programming) chain.

Root Cause

The root cause of CVE-2024-28861 is the absence of type checking and validation in the __unserialize() method of the affected classes. Prior to the patch, the methods blindly accepted and processed deserialized data without verifying:

1. Whether the input is actually an array
2. Whether the array contains the expected number of elements
3. Whether the data types within the array match expected types

This lack of validation allows attackers to inject malicious objects that execute arbitrary code when their magic methods (__destruct(), __wakeup(), __toString(), etc.) are triggered during or after deserialization.

Attack Vector

The attack is network-based and requires the target application to deserialize user-controlled input using the vulnerable Symfony 1 classes. An attacker would:

1. Identify an application endpoint that deserializes user input
2. Craft a malicious serialized PHP object payload containing a gadget chain
3. Submit the payload to the vulnerable endpoint
4. Upon deserialization, the gadget chain executes, achieving remote code execution

The vulnerable __unserialize() method in sfNamespacedParameterHolder before the patch:

/**
 * Unserializes a sfParameterHolder instance for PHP 7.4+.
+* [CVE-2024-28861] Check type of returned data to avoid deserialization vulnerabilities.
 *
 * @param array $data
 */
public function __unserialize($data)
{
+    if (!is_array($data) || 2 !== \count($data)) {
+        $this->default_namespace = null;
+        $this->parameters = [];
+
+        return;
+    }
+
    $this->default_namespace = $data[0];
    $this->parameters = $data[1];
}

Source: GitHub Commit Reference

The patch for sfParameterHolder follows a similar pattern:

/**
 * Unserializes a sfParameterHolder instance for PHP 7.4+.
+* [CVE-2024-28861] Check type of returned data to avoid deserialization vulnerabilities.
 *
 * @param array $data
 */
public function __unserialize($data)
{
+    if (!is_array($data)) {
+        $this->parameters = [];
+
+        return;
+    }
+
    $this->parameters = $data;
}

Source: GitHub Commit Reference

Detection Methods for CVE-2024-28861

Indicators of Compromise

• Unusual serialized PHP data in HTTP request parameters, cookies, or POST bodies
• Web server logs containing base64-encoded or URL-encoded serialized PHP objects
• Unexpected process spawning from PHP-FPM or Apache/Nginx worker processes
• File system modifications in web directories or temporary locations
• Network connections to external hosts initiated by the web server process

Detection Strategies

• Implement web application firewall (WAF) rules to detect and block serialized PHP object patterns in requests
• Monitor application logs for deserialization errors or exceptions that may indicate exploitation attempts
• Deploy runtime application self-protection (RASP) solutions to detect object injection attacks
• Review code for usage of unserialize() on user-controlled input, particularly involving sfParameterHolder or sfNamespacedParameterHolder

Monitoring Recommendations

• Enable detailed PHP error logging to capture deserialization failures and type mismatches
• Configure intrusion detection systems (IDS) to alert on patterns matching PHP serialized object injection payloads
• Implement file integrity monitoring on web application directories
• Monitor process creation events for unusual child processes spawned by web server workers

How to Mitigate CVE-2024-28861

Immediate Actions Required

• Upgrade Symfony 1 to version 1.5.19 or later immediately
• Audit all application code for usage of unserialize() with user-controlled data
• Implement input validation and sanitization on all external data sources
• Consider using safer alternatives to PHP serialization such as JSON encoding where possible

Patch Information

The vulnerability is fixed in Symfony 1 version 1.5.19. The patch adds type checking to the __unserialize() methods in both sfParameterHolder and sfNamespacedParameterHolder classes, ensuring that deserialized data matches the expected array structure before processing. For detailed patch information, see the GitHub Security Advisory and the patch commit.

Workarounds

• Avoid deserializing user-controlled input entirely where possible
• Implement a custom safe deserialization wrapper that validates data types before processing
• Use JSON or other safe serialization formats instead of PHP serialization for user data
• Apply web application firewall rules to block requests containing serialized PHP objects

# Update Symfony 1 using Composer
composer require friendsofsymfony1/symfony1:^1.5.19

# Verify the installed version
composer show friendsofsymfony1/symfony1 | grep versions