Your WordPress site has been hacked: what to do, in order

Your WordPress site is hacked: contain first

Before investigating, stop the damage growing. A compromised site may be sending spam, serving malware to visitors, or being used to attack other systems, and every hour of that increases the reputational and legal exposure.

1. Put the site into maintenance mode or take it offline. A brief planned outage is better than continuing to serve malware
2. Take a full forensic copy of files and database before you change anything. You will need it to understand what happened
3. Notify the host. Many have security teams, and some will have already flagged the account
4. If payment or personal data may be involved, start the disclosure clock immediately. Regulatory deadlines are shorter than most people assume

WordPress hacked: assess what happened

The goal is to establish the entry point, the extent of the compromise, and whether data was taken. That is three separate questions and the third is the one clients care about most.

Find the entry point

• Check for files modified around the time symptoms began, which narrows the search dramatically
• Compare core files against a clean WordPress release; core files should never differ
• Review the list of plugins and themes for anything with a known vulnerability, particularly ones behind on updates
• Check for administrator accounts you do not recognise, and for existing accounts whose role was recently elevated
• Look at server access logs around the first modified file for the request that created it
• Check scheduled tasks for entries that reinstall payloads

In practice, the entry point is a vulnerable plugin far more often than anything else, followed by weak or reused administrator credentials, followed by compromised hosting or FTP access. Sophisticated targeted attacks against small business WordPress sites exist but are not the common case.

Establish the extent

Look for injected content in posts and options, modified .htaccess rules, unfamiliar files in the uploads directory, backdoors in the theme's functions.php, and additions to wp-config.php. Backdoors are frequently placed in several locations specifically so that removing one still leaves access.

Clean up properly

For most compromises, restoring a known-clean backup and then patching the vulnerability is faster and more reliable than manual cleaning, because it guarantees you have not missed a backdoor. The critical word is known-clean: if the compromise happened three weeks ago and you restore from last week, you restore the backdoor along with everything else.

1. Restore from a backup predating the compromise, or replace core, plugins and themes with fresh copies from source
2. Never restore plugin or theme files from the compromised site; download them fresh from their origin
3. Manually review wp-config.php, .htaccess and the uploads directory, which restores do not always fully clean
4. Update everything to current versions before bringing the site back online
5. Rotate every credential: WordPress users, database, hosting, SFTP, API keys, and anything reused elsewhere
6. Force a password reset for all users and invalidate existing sessions

The conversation with your client

This is the part agencies handle worst, usually by delaying until they have good news. Clients tolerate a security incident considerably better than they tolerate discovering you knew about it for two days and said nothing.

• Tell them early, with what you know and what you do not yet know
• Be specific about whether customer data may be involved, because that determines their legal obligations as well as yours
• Give a realistic timeline rather than an optimistic one
• Follow up with a written account of the cause and what has changed to prevent recurrence
• If personal data was accessed, they may have regulatory reporting duties with short deadlines. Say so explicitly rather than assuming they know

Preventing the next one

Almost every WordPress compromise an agency deals with traces back to a component with a known, published vulnerability that had a patch available. The attack was not clever; the patching was slow. That is uncomfortable but it is also good news, because it means the fix is operational rather than technical.

• Monitor for known vulnerabilities across the whole portfolio rather than site by site
• Prioritise by exposure: a vulnerable plugin on eleven client sites matters more than one on a staging copy
• Patch security releases quickly, with a restore point taken automatically so speed does not mean risk
• Enforce strong unique credentials and two-factor authentication for administrators
• Remove unused plugins and themes entirely; deactivated code is still code on disk
• Keep off-site backups in a different failure domain, with retention long enough to predate a slow-burning compromise
• Review administrator accounts regularly, especially after staff or contractors leave