The PHP object injection in this plugin exists because allowed_classes provides a false sense of security. The parameter was introduced in PHP 7.0 specifically to address gadget chains — legitimate class methods that attackers chain together during object lifecycle events like destruct() or wakeup() to achieve code execution. It does not prevent this. A developer who added allowed_classes but stopped there has addressed the naive unserialize attack while leaving the actual exploitation pathway intact.
The deeper problem is that this is not an isolated failure. PHP's serialize/unserialize API has enabled object injection attacks since 2009, and the language has never deprecated it. The security community published gadget chain research, wrote advisories, and added allowed_classes — but the PHP manual entry for unserialize does not carry a prominent warning that this parameter does not address object lifecycle injection. The mitigation propagated through the ecosystem as if it closed the attack class entirely. It did not.
For defenders, the practical implication is that any unserialize() call receiving user input is critical regardless of allowed_classes presence. Static analysis tools that treat allowed_classes as reducing severity are perpetuating the same false assurance that enabled this vulnerability. But the most important reframing is blast radius: a successful object injection exploit in a widely-deployed WordPress plugin doesn't just compromise the target site — it potentially reaches every instance running that plugin simultaneously. This is an asymmetric risk that CVSS undersells. The technical sophistication of the exploit matters less than the breadth of the target set.
Prioritise object injection findings in widely-deployed codebases not because they are novel, but because a single successful gadget chain can detonate across hundreds of thousands of sites. The attack surface persists long after the developer stops maintaining the code.