Simple enough vulnerable, a POST parameter was directly unserialized, which would often be pretty damning, but vBulletin apparently had put in some effort to make it hard to exploit.

There is no universal deserialization gadget for RCE in PHP, each attacker is going to depend on the classes the application itself has and if they do anything sensitive. In vBulletin’s case, they take an extra step and protect many of their classes from being targets by implementing trails that raise exceptions when they are deserialized severely limiting the targets.

They did find that in the packageas path there was a vulnerable class, packages/googlelogin/vendor/monolog which has a known deserialization gadget, the problem was despite the code existing, as it wasn’t included on the page the necessary classes could not be deserialized.

To get aorund this they abuse vBulletin’s class autoloader. If you’re unfamiliar with autoloading in PHP you can provide a function to PHP that is called whenever it tries to create a class it doesn’t know about giving that function a chance to include any files that might be necessary. The authors here were able to abuse vBulletin’s autoloader by first trying to deserialize the googlelogin_vendor_autoload class, which the autoloader would see and then load the packages/googlelogin/vendor/autoload.php file. Which would include the needed monoglog file, allowing the known deserialization gadget to be used.

Autoloading is a weird feature in PHP, really powerful, and used somewhat silently because it makes developer’s lives easier, but as seen here it can be a useful gadget in an exploit chain.