Why your WordPress site keeps getting hacked, and what finally stops it

A WordPress site that is infected again after a cleanup was either never fully cleaned, or is still open the way it was first entered. Google's guidance for hacked sites says an attacker may leave a back door that lets them return, or that puts back the code you removed. The reasons come down to eight, and each one can be checked.

This page is for when a first cleanup was not enough. For the first one, use how to remove malware from a hacked WordPress site.

Why a cleaned site is infected again

More than one can be true at once. Google's guidance says there may be several independent hacks in place, and recommends that you keep looking after you find the first.

A backdoor was left behind

A backdoor is a file, or a few lines inside a real file, that lets the attacker back in without the original hole. Removing what a scanner flags removes only what that scanner recognized. Look where code runs without anyone activating it.

• wp-content/mu-plugins. WordPress loads every PHP file directly in this folder, before the ordinary plugins. These files cannot be disabled from the dashboard, and the Plugins screen shows them only in a separate "Must-Use" section.
• Drop-ins. WordPress loads a few files by name when they sit directly in wp-content: object-cache.php, db.php, db-error.php, maintenance.php, php-error.php, fatal-error-handler.php, install.php, and advanced-cache.php when WP_CACHE is on. A caching plugin may own one.
• Files named like WordPress's own, added to wp-admin or wp-includes. The checksum command warns about each file that should not exist.
• .htaccess and .user.ini in any folder. Apache applies an .htaccess file to its folder and every folder under it. PHP running as CGI or FastCGI reads a .user.ini in the requested file's folder and each folder above it, and its auto_prepend_file setting names a file to run ahead of the requested one.
• The uploads folder. The cleanup below has the command.

ls -la wp-content/mu-plugins/ wp-content/*.php
find . -type f \( -name ".htaccess" -o -name ".user.ini" \)
wp core verify-checksums --include-root

Use ls and not wp for the first, because wp would run those files. If there is no mu-plugins folder, ls says so and lists the rest. Apart from the drop-ins, the only PHP file WordPress ships directly in wp-content is a small index.php. --include-root also warns about files in the main folder that are not part of WordPress. Some will be yours. Open whatever you cannot account for.

What fixes it. Finding one backdoor does not show there is no second. The cleanup below builds the site again in an empty folder, so a planted file has nowhere to stay.

The backup you restored was already infected

Google's guidance says to check that a backup was made before the site was hacked, which is not the same as before the day you noticed. WordPress's hardening guide gives the example of a site compromised on the first of the month and not detected until the twelfth.

Compare the backup's date with the earliest sign you can find: the oldest file the attacker added, or the registration date of an administrator nobody created. Then run the checks on this page on the restored site, as if it had never been cleaned.

A clean backup also restores the hole: the same out-of-date plugin, the old passwords and the old secret keys.

What fixes it. Go further back, or rebuild as described below. After either, Google's guidance is to upgrade all the software, remove what is not used and change every password.

The vulnerable plugin or theme is still installed

Cleaning removes what the attacker planted and leaves the hole it came through. WordPress's hardening guide points out that once a fix is released, what is needed to exploit the hole is almost certainly public.

wp plugin list --fields=name,status,version,update,wporg_status --skip-plugins --skip-themes

• update says whether a newer version is waiting.
• wporg_status should read active. closed is not proof by itself: the column can also show it for a plugin that was never on WordPress.org, such as a paid or custom one. For anything but active, open the plugin's page on WordPress.org. A closed plugin's page says it is no longer available for download. A security issue is one of the listed reasons for closing one, and the reason is shown only after 60 days.
• The plugin's own page shows when it was last updated. It warns when it has not been tested with the three latest major releases of WordPress, and says it may no longer be maintained.

"Nulled" software is a paid plugin or theme obtained from somewhere other than its author. WordPress's hardening guide says not to get plugins or themes from untrusted sources, and to keep to the WordPress.org repository or well-known companies. Google's guidance gives the reason: adding malicious code to free versions of paid plugins and themes is a common tactic. Reinstalling such a copy reinstalls whatever was added to it.

What fixes it. Update what has an update. Delete what you do not use, as the hardening guide says. Replace a closed or abandoned plugin with a maintained one, and a nulled copy with one from the author. How to audit a WordPress site for security weaknesses shows how to look up each plugin's known vulnerabilities.

The attacker still holds a credential

A password changed while the attacker still had a way in was changed in front of them. WordPress's documentation says to change the passwords again once the site is clean, for every user with access, and lists the access points: FTP or SFTP, the dashboard, the hosting control panel and the database.

List the application passwords on each administrator's account, with the user's ID in place of 1. last_used and last_ip show whether one is in use and from where. created and last_used are printed as Unix timestamps, and date -u -d @1791390665 turns one into a date. wp user application-password delete 1 --all removes all of that user's.

wp user application-password list 1 --fields=uuid,name,created,last_used,last_ip --skip-plugins --skip-themes

wp config shuffle-salts replaces the secret keys. Without WP-CLI, the salt generator makes a fresh set to paste over the eight lines.

What fixes it. Change all of them in one sitting, after the rebuild and from a computer you have scanned. Then turn on two-factor authentication for every administrator.

An administrator or a scheduled task puts it back

An administrator account, a scheduled event in WordPress and a job in the server's own scheduler all sit outside the files a cleanup replaces.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themes
wp cron event list --skip-plugins --skip-themes
crontab -l

• Administrators. Every name should be a person you can account for. Then run the list once more without --role=administrator and with roles added to --fields, and account for every account above Subscriber. A capability granted to one account directly does not show in that column. What to do about an administrator nobody created has the database query that shows it. Deleting an unknown one is not enough by itself, because whatever created the account is still there.
• Scheduled events. Each row is a hook and the time it next runs. wp_version_check, wp_update_plugins and wp_update_themes are WordPress's own. WordPress's documentation notes that a scheduled task goes on being attempted even after the plugin that set it is removed. For a hook you do not recognize, find the file that names it with grep -rl "hook_name" wp-content. If nothing you installed accounts for the file, remove it, then the event, with wp cron event delete hook_name.
• The crontab. Each user on a server can have a table of scheduled commands, kept outside the site's folder. crontab -l prints yours and crontab -e edits it. A line you did not add comes out, above all one that fetches from another address or runs a PHP file.

Another site in the same hosting account

WordPress's hardening guide says that on a shared server, a compromised site can lead to yours being compromised even if you follow everything in the guide.

File permissions do not protect sites under one account from each other. A permission mode sets what a file's owner, its group and everyone else may do. WordPress's documentation describes the setup many shared hosts use, in which PHP runs as the owner of the PHP files. Every site in one account has the same owner. So code running in one site is the owner of the other site's files, and the 644 and 755 modes that keep strangers out give the owner write access. The file permissions guide explains the digits.

find ~ -type f -name "wp-config.php"

Each line is a WordPress installation: the live sites, and also an old staging copy or a test site nobody remembers.

What fixes it. Give every site on the account the same cleanup at the same time, and delete the ones nobody uses. Ask your host whether each site can have an account of its own. The hardening guide also suggests a separate database and database user for each site.

The infection is in the database

Replacing every file leaves the database as it was. Google's guidance describes an attacker inserting malicious code into every record of a database table.

wp option get siteurl --skip-plugins --skip-themes
wp option get home --skip-plugins --skip-themes
wp db search "<script" --skip-plugins --skip-themes

The first two should print your own address and nothing else. The third searches every text column of the tables WordPress has registered and prints the table, the column, the row and the text around each match. Expect some matches of your own, such as an embed in a post. Search as well for any domain that appeared in the injected content. Add --all-tables-with-prefix to include tables that plugins created.

Read every snippet in any plugin that stores code in the database and runs it. The hardening guide warns that such plugins magnify the damage of a successful attack.

What fixes it. Remove injected content through the screen that owns it, such as the post editor or the widgets screen. Restoring the database from before the break-in also works, and loses everything added since.

The computer or the password on your side

WordPress's documentation says that in many instances the attack begins on the owner's own computer, where malware captures the logins for FTP and the dashboard. A password changed on that computer can be captured as it is typed. A reused password fails the same way: Google's guidance notes that attackers who find a working username and password try the pair on as many services as they can.

What fixes it. Google recommends running several reputable antivirus scanners on every computer an administrator has used to log in. Do that before changing any password, then give every account a password used nowhere else.

Find the way in from the access log

The access log records the requests the server handled. Read around the time files changed, and it can show which request put them there. Ask your host for it early, because it reaches back only as far as the host keeps it.

The log can show which file was requested, when, from which address, and whether the request succeeded. It cannot show:

• What was sent. The standard formats record the request line, the status and the size, not the body of a POST.
• Who it was. The hardening guide notes that logs do not record which username logged in, and Apache's documentation adds that the address may be a proxy's. A login with a stolen password looks like any other.
• Anything that did not come through the website, such as a file placed over SFTP.
• That it is complete. Google's guidance warns that the attacker may have altered the logs.

If the log does not settle it, treat all eight reasons as open.

A cleanup that holds

Hunting for infected files one at a time is what failed the first time. This cleanup builds the site again from sources you can trust and carries over three things only: wp-config.php after you have read it, the media after you have checked it, and the database after you have searched it.

Before you start, take the site offline and keep a copy of it as it is, as the hacked site runbook describes. Scan the computers you work from. Do every WordPress on the hosting account in the same sitting. In the commands the old folder is public_html and the new one clean. Use your own folder's name.

The rule that stops PHP in uploads

The nginx rule is the one in WordPress.org's nginx documentation. The Apache rule uses two directives from Apache's documentation: FilesMatch, which may be used in .htaccess, and Require all denied.

<FilesMatch "\.(php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

The Apache rule works only where the host lets .htaccess files set access rules. The nginx rule goes in the site's server block, above the block that hands .php files to PHP, because nginx checks regular expressions in order and stops at the first match. On managed hosting, ask the host to add it. Either rule stops a browser from requesting those files, and does not stop WordPress from reading a file a plugin keeps there. To test, put an empty test.php in uploads, request it, expect a 403 error, and delete it.

What to watch in the first weeks

WordPress's hardening guide recommends monitoring a site's files for changed and added files. When the cleanup is finished, and again after each update you run yourself, make a marker with touch ../clean-marker. Then check every few days at first, and weekly after that:

find . -type f \( -name "*.php" -o -name ".htaccess" -o -name ".user.ini" \) -newer ../clean-marker
wp core verify-checksums --include-root
wp plugin verify-checksums --all --skip-plugins --skip-themes

• Changed files. The first command lists every PHP and configuration file changed since the marker. With no update in between, it should print nothing. The checksum commands compare contents, so a changed file is reported even when its date was set by hand. Read every line they print, not only the last: an added file appears as Warning: File should not exist above a line that still says Success.
• New users. Run the administrator list again, and look at each administrator's application passwords.
• Scheduled events and the crontab. One that has returned means the code that sets it is still on the server.
• Google's Security issues report. In Search Console it lists what Google has found on the site. If the site was flagged, select "Request Review" only once the whole site is clean. The hacked-site check reads the site from outside and reports signs, not a verdict.

If something comes back, write down the first file that changed and its time before you remove it. That time, taken to the access log, can show which of the eight reasons was missed.

After several quiet weeks, move on to prevention. The WordPress security guide sets out what to tighten, in order, and WordPress firewalls compared covers what a firewall can and cannot filter.

When to hand it over

Get help when:

• the infection returns after a rebuild like the one above;
• the site runs a custom theme or plugin and you have no clean original of it;
• you cannot get SSH access, the access log or a list of the other sites on the account;
• the site holds customer accounts, orders or payment details.

Our malware removal service is a one-time clean-up with hardening, a blacklist removal request and a written report, and if the infection comes back within 30 days we clean the site again. Scanning, updates and backups from then on are what a care plan does, described under WordPress security.