CVE-2026-27206: Verified Repro With Script Download

GHSA-v7m3-fpcr-h7m2: Zumba Json Serializer PHP Object Injection via @type

Summary

The zumba/json-serializer library prior to version 3.2.3 contains a PHP Object Injection vulnerability in its JSON deserialization functionality. The JsonSerializer::unserialize() method accepts a special @type field in JSON that specifies which PHP class to instantiate. In vulnerable versions, there is no validation or restriction on which classes can be specified, allowing an attacker to instantiate arbitrary PHP classes. When combined with classes that have dangerous magic methods like __wakeup() or __destruct(), this can lead to gadget chain attacks and potentially Remote Code Execution (RCE).

Impact

Package: zumba/json-serializer
Affected Versions: < 3.2.3
Patched Version: 3.2.3
CVE: CVE-2026-27206
CVSS Score: 8.1 (HIGH)

Risk Level: High - This vulnerability allows arbitrary class instantiation when attacker-controlled JSON is passed to the deserializer. If the application or its dependencies contain classes with dangerous magic methods (such as __wakeup() or __destruct()), this may lead to:

• Remote Code Execution (RCE) via gadget chains
• Data exfiltration
• File manipulation
• Denial of service

Prerequisites for Exploitation:

1. Untrusted/attacker-controlled JSON passed to JsonSerializer::unserialize()
2. Presence of exploitable classes (gadget chains) in the application or dependencies

Root Cause

The vulnerability exists in the unserializeObject() method in src/JsonSerializer/JsonSerializer.php. When deserializing JSON containing an @type field:

1. The method extracts the class name from @type without any validation
2. It checks if the class exists using class_exists($className)
3. If the class exists, it instantiates the class directly using new $className() or $ref->newInstanceWithoutConstructor()
4. No check is performed to restrict which classes may be instantiated

Vulnerable code pattern (v3.2.2):

protected function unserializeObject($value)
{
    $className = $value[static::CLASS_IDENTIFIER_KEY]; // @type value
    unset($value[static::CLASS_IDENTIFIER_KEY]);
    
    // ... recursion handling ...
    
    if (!class_exists($className)) {
        throw new JsonSerializerException('Unable to find class ' . $className);
    }
    
    // No allowed class check - ANY class can be instantiated!
    $ref = new ReflectionClass($className);
    $obj = $ref->newInstanceWithoutConstructor();
    // ...
    if (method_exists($obj, '__wakeup')) {
        $obj->__wakeup(); // Magic method called!
    }
}

The Fix (v3.2.3): The fix introduces a setAllowedClasses(?array $allowedClasses) method that allows applications to specify which classes may be instantiated during deserialization. When configured, the unserializeObject() method validates the class name against the allowed list before instantiation.

Fix commit: 88b44c5 Adding method to restrict classes allowed on unserialize

Reproduction Steps

The reproduction script is located at: repro/reproduction_steps.sh

What the script does:

1. Clones the zumba/json-serializer repository
2. Checks out the vulnerable version 3.2.2
3. Installs PHP dependencies via composer
4. Creates and executes a PHP test script that:
   • Instantiates the JsonSerializer
   • Creates a malicious JSON payload with @type specifying an arbitrary class
   • Calls unserialize() with the malicious payload
   • Verifies that the arbitrary class is instantiated
   • Confirms that __wakeup() is called (demonstrating the danger)
   • Checks for the absence of setAllowedClasses() method

Expected Evidence:

[TEST] Malicious JSON payload: {"@type":"VulnerableTarget","data":"injected"}
[VULNERABILITY CONFIRMED] __wakeup() was called on arbitrary class!
[RESULT] Class instantiated: VulnerableTarget
[RESULT] __wakeup() called: YES
[CHECK] setAllowedClasses() method: MISSING (vulnerable)
=== CONCLUSION ===
VULNERABILITY CONFIRMED: Arbitrary class instantiation works!

Evidence

Log Location: logs/repro_output.log

Key Excerpts:

=== GHSA-v7m3-fpcr-h7m2 Reproduction Script ===
[TEST] Malicious JSON payload: {"@type":"VulnerableTarget","data":"injected"}
[VULNERABILITY CONFIRMED] __wakeup() was called on arbitrary class!
[RESULT] Class instantiated: VulnerableTarget
[RESULT] Data value: injected
[RESULT] __wakeup() called: YES
[CHECK] setAllowedClasses() method: MISSING (vulnerable)
VULNERABILITY CONFIRMED: Arbitrary class instantiation works!

Environment Details:

• PHP Version: 8.4.18
• Package: zumba/json-serializer v3.2.2
• OS: Linux (Debian-based)

Recommendations / Next Steps

Immediate Actions:

1. Upgrade to version 3.2.3 or later immediately
2. Configure allowlist: After upgrading, use setAllowedClasses() to restrict which classes may be deserialized:

   $serializer = new JsonSerializer();
   $serializer->setAllowedClasses(['AllowedClass1', 'AllowedClass2']);
   

3. Audit applications using this library to ensure they don't process untrusted JSON input

Testing Recommendations:

1. Add unit tests that attempt to instantiate disallowed classes
2. Implement input validation before passing JSON to the deserializer
3. Consider using a Web Application Firewall (WAF) rule to detect @type fields in untrusted input
4. Review dependency tree for exploitable gadget chains (using tools like PHPGGC)

Long-term:

• Consider using alternative serialization formats with built-in type safety
• Implement defense-in-depth with additional input validation layers

Additional Notes

Idempotency Confirmation: The reproduction script has been run twice consecutively with identical results:

• Run 1: Exit code 0 (vulnerability confirmed)
• Run 2: Exit code 0 (vulnerability confirmed)

Edge Cases:

• The vulnerability only affects applications that deserialize untrusted JSON input
• Applications that only deserialize trusted/internal data are not affected
• The impact depends on available gadget chains in the application or its dependencies

Limitations:

• This reproduction demonstrates the class instantiation capability but does not demonstrate actual RCE
• Full RCE would require a suitable gadget chain in the target application dependencies
• The fix in v3.2.3 is opt-in (requires calling setAllowedClasses()) for backward compatibility