A hacked WordPress site: an outdated plugin and a web shell

The site runs on WordPress with several plugins. One of them, wp-file-manager, is on a version from before the fix. The admin login is publicly reachable, file editing is enabled in the admin, and the WordPress database account has full rights.

Backups exist, but nobody has tried to restore one, and file integrity is not monitored.

Customers reported that on mobile the site redirected to a dubious page. Google Search Console flagged the site as harmful and organic traffic dropped.

The cause was CVE-2020-25213 in the wp-file-manager plugin before version 6.9. The plugin exposed a file through which PHP code could be uploaded and run without signing in, that is, remote code execution. The attacker uploaded a web shell, a small PHP file for controlling the server, and injected a conditional redirect into the site (on mobile and from search results) along with spam content for search engines.

Prerequisite: it is enough that the vulnerable plugin is reachable from the internet. This is a publicly known, mass-exploited vulnerability from 2020, nothing we are disclosing here.

A hacked site means the server was under the attacker's control. So it was treated on the basis that nothing on it can be trusted any more.

The main cause is an outdated plugin with a known vulnerability. With no update tracking, it stayed open for months after the fix shipped.

The impact was widened by settings: file editing enabled in the admin and a database account with full rights broadened what could be done after the first foothold. PHP could also run from the uploads directory, where the shell landed.

That nobody had tried to restore a backup and integrity was not monitored meant the compromise showed up only through customer complaints, not sooner.

File modification times showed unknown PHP files in the uploads directory and edited theme files. In the database, injected code sat in the settings and in the page content.

The Nginx access logs showed requests to the plugin's file from foreign addresses at the time the unknown files appeared.

Search Console showed which URLs Google had flagged and what it was showing visitors.

The extent was confirmed by comparing against a clean install of WordPress and the plugins from official sources, to make clear what did not belong on the server.

The site was taken into maintenance mode. The shell was not simply deleted: after a compromise there is no reliable way to prove the attacker left no other backdoor, so the site was rebuilt.

The WordPress core, the plugins and the theme were replaced from official sources. Content was restored from a verified clean backup, or the database was cleaned of the injected code. The wp-file-manager plugin was removed, since the site did not need it.

All secrets were rotated: administrator passwords, the database password, the security keys in wp-config.php (which invalidates every login), and the hosting credentials.

// turn off the built-in file editor in wp-admin: no code changes from the browser
define('DISALLOW_FILE_EDIT', true);

// rotate ALL of these after a compromise, with fresh values from the
// WordPress secret-key API; it invalidates every existing login cookie
define('AUTH_KEY',         '...'); // also SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY
define('AUTH_SALT',        '...'); // also SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT

Running PHP from the uploads directory was forbidden, so any further shell dropped there stays inert.

# never run PHP from the uploads directory: a web shell dropped there stays inert
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

The site was hardened: file editing in the admin turned off, the database account cut to only the rights it needs, automatic plugin updates, a second factor and a limit on login attempts for the admin, and file integrity monitoring.

In Search Console the company requested a review so Google would clear the flag.

Removing the plugin closes the path the shell was uploaded through. An update would close it too, but the plugin was not needed.

Rebuilding from official sources also removes any backdoor that manual cleaning might miss.

Rotating the security keys in wp-config.php invalidates every login cookie, so the attacker cannot return through an old session.

Forbidding PHP in the uploads directory means that even if another shell lands there, the server will not run it.

File editing off and a least-privilege database account shrink what can be done after a future flaw.

What it does not address: a vulnerability in a plugin you keep, or a flaw in hosting shared with other sites. That is why updates and keeping plugins few matter.