Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-v7m3-fpcr-h7m2
No affected components available
Description
The zumba/json-serializer library allows deserialization of PHP objects from JSON using a special @type field.
Prior to version 3.2.3, the deserializer would instantiate any class specified in the @type field without restriction. When processing untrusted JSON input, this behavior may allow an attacker to instantiate arbitrary classes available in the application.
If a vulnerable application passes attacker-controlled JSON into JsonSerializer::unserialize() and contains classes with dangerous magic methods (such as __wakeup() or __destruct()), this may lead to PHP Object Injection and potentially Remote Code Execution (RCE), depending on available gadget chains in the application or its dependencies.
This behavior is similar in risk profile to PHP's native unserialize() when used without the allowed_classes restriction.
Impact
This vulnerability allows instantiation of arbitrary PHP classes via the @type field when deserializing JSON.
Applications are impacted only if:
- Untrusted or attacker-controlled JSON is passed into
JsonSerializer::unserialize(), and - The application or its dependencies contain classes that can be leveraged as a gadget chain.
Successful exploitation may lead to:
- Arbitrary code execution
- Data exfiltration
- File manipulation
- Denial of service
Applications that only deserialize trusted data are not affected.
Patches
This issue is mitigated in version 3.2.3.
Version 3.2.3 introduces the method: setAllowedClasses(?array $allowedClasses)
This allows applications to restrict which classes may be instantiated during deserialization, similar to PHP's native unserialize() allowed_classes option.
Users should upgrade to version 3.2.3 or later and configure an appropriate class allowlist.
Workarounds
If upgrading is not immediately possible, applications should ensure that:
JsonSerializer::unserialize()is never called on untrusted or attacker-controlled JSON.- JSON input is validated and sanitized before deserialization.
- Object instantiation via
@typeis disabled in application logic where possible.
After upgrading, users can mitigate risk by explicitly configuring:
$serializer->setAllowedClasses([]);
to disable all object instantiation, or by providing a strict allowlist of safe classes.
References
- CWE-502: https://cwe.mitre.org/data/definitions/502.html
- PHP
unserialize()documentation: https://www.php.net/manual/en/function.unserialize.php - OWASP PHP Object Injection: https://owasp.org/www-community/vulnerabilities/PHP_Object_Injection
The vulnerability can be exploited over the network without needing physical access. It is difficult for an attacker to exploit this vulnerability and may require special conditions. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data. There is a high impact on the availability of the system.
Exploitation activity has been observed. Apply available patches or mitigations urgently.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard