Security Exploit Patched on vBulletin – PHP Object Injection

The vBulletin team just issued a warning, and released patches for a security exploit that affected all versions of vBulletin including 3.5, 3.6, 3.7, 3.8, 4.X, 5.X. They recommend that anyone using vBulletin apply these patches as soon as possible. Here is part of their announcement:

A security issue has been found that affects all versions of vBulletin including 3.x, 4.x and 5.x. We have released security patches to account for this vulnerability. This includes patches for vBulletin 3.8.7, vBulletin 4.2.2 and all versions of vBulletin 5 (including Cloud accounts). The patch is also applied to vBulletin 5.1.0 RC1. It is imperative that you apply these patches as soon as possible.

Due to functionality changes, the minimum PHP version for the patch is 5.2.0. This represents an increase for vBulletin 3. Alternatively customers can install the JSON functions separately in which case it will work with any compatible PHP version that their particular version of vBulletin supports. You will need to collaborate with your hosting provider or systems administrator to apply the changes to PHP.

If you are using vBulletin, you know what to do: Patch now!

What really worries me from this announcement is that they increased their minimal PHP version requirement on the security patch. It means many webmasters will not be able to apply the patch quickly enough, and some may end up breaking their sites.

So, if your host is not running an updated version of PHP, you need to contact them ASAP to get it updated or your site will be vulnerable.

What a Security Exploit Means?

The vBulletin team provided no details on what exactly they patched, or what the vulnerability was. All they have said is it was a “security exploit”, which should be enough of a warning for people to update their forums.

Based on their patches, we were able to clearly see what the issue was:

They removed:
$temp = unserialize($check);
And added:
$temp = json_decode($check, true);

Later in the code where they were running “serialize($_POST”, they changed it to “json_encode($_POST)”. It appears like a PHP Object injection where they are passing user supplied data to an “unserialize” function.

This may lead to privilege escalation, remote code execution, or maybe even allow an attacker to run any PHP function they want. We don’t know how bad it is yet, but our team is still investigating this issue and trying to confirm the severity, and what can really be done.

Users running our Website Firewall are already protected against PHP Object injections, and we are building a custom virtual patching signature for it as well. Stay tuned for updates.

Scan your website for free:
About Daniel Cid

Daniel B. Cid is the CTO&Founder of Sucuri and the founder of the open source OSSEC HIDS. His interests range from intrusion detection, log analysis (log-based intrusion detection), web-based malware research and secure development.

You can find more about Daniel at his site dcid.me or on Twitter: @danielcid

  • Genious

    So nobody knows what the potential issue with this exploit is and everyone is jumping on the RCE boat as usual. Security experts scratching there heads hmmm.

    I’ve yet to see any kind of POC of this apparent exploit, looks to me vB finally got off there ass and realised they unserialized user input and just issued a patch incase there was a security rick. The only magic function you can inject with the object injection is __destruct which unlinks a file.