This guide is for what to do, after you’ve been hacked, exploited, and or defaced.

Step 1, Change everything:

If you believe, or think your site has been hacked or defaced, you should first start by changing all of your passwords: FTP/SFTP/SSH, cPanel, MySQL, email passwords (if you were using SMTP for vBulletin). This is important, it helps to make sure getting back in, once you’ve cleaned house is much harder. You should also change your vBulletin login, but only after you make sure they shouldn’t be able to get it again, we’ll cover that in step 2.
If you need a help changing these things, you should contact your webhost. They should be able to help you change all of the above, with the exception for the vBulletin login.

Step 2, Restoring the default vBulletin files:

You should login to the Members Area(link) and download a fresh copy of either your current version of the software, or the latest stable version for your current major version. For example, if you were on 5.0.3, you’d want to upgrade to 5.0.4.

If you need help upgrading, see this: Extract the zip file, and upload the contents of the upload folder. Pay attention to remove the install folder, if you’re not upgrading, or after you’re done upgrading.

Once all of the files have been uploaded, you should also add the following line to your includes/config.php file (core/includes/config.php for vBulletin 5 users)
define("DISABLE_HOOKS", true);
This will shut down the plugin system, if you’ve uploaded clean files, this should prevent someone from gaining your admincp login again, should they have left something nasty behind in the plugin system.

Once this is done, make sure to change your admin password. If for some reason you cannot login to the admincp, see step 3.

Step 3, Recovering Admin access:

In some cases, the hacker will remove your admin access, you can restore access to your admincp via tools.php.
You would upload tools.php to the admincp (vB3 or vB4), or core/admincp (vB5) folder, then go to
Enter your customer number, then for the reset admin access, enter your username.
For some reason, if your admin username is gone, or has been deleted, you can create a new user, via registering normally on your site, then promote it to an administrator. Though, you may wish to look at step 4 as an alternative.

Step 4, Restoring a database:

If for some reason the damage to your site is too extreme, or hard to recover, restoring a backup from a previous time is the next safest move. Hopefully you’ve been taking good backups, or your webhost has a backup of the site prior to it being broken into.
You should restore the backup of the database to its own new database name, and have it use a new database user/password as well. This also avoids issues that might come up from exploited code by using a new database. It keeps it so there is nothing left over from the old exploit.
It would generally be recommended to use a backup if you have one available, though we know this is not always the case.

Step 5: Removing unknown files:

In general, it’s a good idea to audit any files that you might not know what they are. The vBulletin AdminCP provides a tool to scan vBulletin directories to see if any files come up as unknown, or mismatched.
If you didn’t personally upload the file yourself, you should remove it, or put it into a folder that not available via the web until you can confirm it’s a file you or someone you trusted uploaded.
If you have third party addons, you should follow the Step 2 advice and reupload their default files.
You should also manually check files outside of the vBulletin directory, something might have been left as a back door to get back in. Your webhost may be able to help with this, don’t be afraid to seek help from them.

Step 6, Removing unknown plugins:

A popular options is to add a custom plugin to the vBulletin product. By default there are no Plugins for the vBulletin product, only plugins that you, another administrator, or third party addon added.
If there are any plugins listed under the vBulletin Product @ AdminCP > Products & Plugins > Plugin Manager, you should disable them, and review each one. If you know the code that was added and know it to be safe, you can leave it active. If you’re unsure of what the plugin code does, you should post in the correct forum on or, or even in the ticket system to ask if it is reasonably safe code to have at that plugin point.
Obfuscated code tends to look similar and is easy to spot, when in doubt disable it and ask for help.

Step 7, Final Cleanups:

Lastly, sometimes malicious hackers will do much more simple things, like edit your templates, notices, announcements, user titles, etc. Depending on what they’ve done, will require you to go and clean up each.

Check your notices, AdminCP > Notices > Notice Manager, make sure everything looks correct.

Check your Announcements, AdminCP > Announcements > Announcement Manager, make sure everything here looks correct.

Check your templates, this can be tricky, but a quick fix would be to add a new style, AdminCP > Styles & Templates > Style Manager > add New Style, then go into the Settings > Options > Style & Language Settings and set it as the new default style. You can then take the time to fix your old styles, or remove them. You’ll have to manually review any customized templates in your style, and make sure they haven’t been modified.

You should also re-import the master style, if you didn’t already run the upgrader. AdminCP > Styles & Templates > Download / Upload Styles, you’ll need to browse and choose the master vbulletin-style.xml from your local vBulletin zip package files, then import it.

Next, check your Ads, AdminCP > Ads > Ad Manager, make sure all of the ads still have your ad code in them.

After that, you’d also want to do a quick review of your usergroup permissions, and user titles: AdminCP > Usergroups > Usergroup Manager, edit each usergroup and double check their permissions. Then check the user titles, AdminCP > Users Titles > User Title Manager. You should also check ranks, AdminCP > User Ranks > User Rank Manager

Step 8, securing your site and moving forward:

Now that you have access back to your site and it should be reasonably safe, you should secure your site via htaccess, NTAuth, or other protections available to your via your webhost. Keeping people out of sensitive areas, like the admincp, etc will help deter future exploits on your website.
You should also remove the
define("DISABLE_HOOKS", true);
Code from your config.php file, so your site comes back to life.
Make sure you read our best practices guide here, as well (link)