Skip to content

Information about the php2shell vulnerability

Read more about the php2shell vulnerability
noen
Contact us
The site is hacked

Check whether your server was attacked through php2shell

Patching doesn't remove a backdoor planted before the fix. How to look for web shells, unknown users and other traces from 20 October onwards.

You need
FTP
Updated

A security patch closes the hole, but it doesn't remove anything an attacker left behind. Details of php2shell leaked on 20 October 2026, and PHP shipped the fix the following day. If your server was attacked before PHP was patched, a backdoor may still be sitting there and working. The checks below look for the traces, and they're worth doing even if PHP is now up to date. For updating PHP itself, see how to patch PHP for php2shell.

Save the logs first

The access and error logs show what happened on the server, but many hosting providers delete them after a few days. Download them before you do anything else, including before you deploy or restart the server. On shared hosting you'll find them in the control panel, often under Logs or Statistics. On your own server they're usually in /var/log/apache2/ or /var/log/nginx/.

Access logs don't record what was in each request, so you won't see the attack itself there. What you can see is what came after, such as requests to PHP files that aren't part of your site.

Look for PHP files that don't belong

A web shell is usually a small PHP file that accepts commands. Attackers tend to put it somewhere it won't draw attention.

  1. Open wp-content/uploads. It should only hold images and documents, and a .php file in there is almost always malicious.
  2. Sort the files in the root folder and in wp-content by date modified, and look for anything changed after 20 October. Watch for names that mimic WordPress files, such as wp-confg.php.
  3. Open .htaccess and .user.ini in the root folder. A line with auto_prepend_file or auto_append_file makes PHP run a given file on every request, which is a common hiding place for a backdoor.
  4. Check wp-content/mu-plugins. Plugins in there load automatically and don't appear in the normal plugin list.

File modification dates can be faked, so an old date doesn't make a file safe. A PHP file in the uploads folder is always suspicious, whatever its date.

Look for new users, scheduled tasks and keys

  • Admin users: Under Users in WordPress, look for admins you don't recognise.
  • Scheduled tasks: On shared hosting, cron jobs are listed in the control panel. On your own server, crontab -l -u www-data and the files in /etc/cron.d/ show what runs.
  • SSH keys: Look for new lines in authorized_keys for the user PHP runs as, often /var/www/.ssh/authorized_keys, and for root.
  • Resource use: A server that suddenly burns CPU or sends a lot of outbound traffic may be mining cryptocurrency or attacking others.

If you find signs of a compromise

If the attacker planted a web shell, they've been able to run commands with the same permissions as PHP. Deleting the file isn't enough.

  1. Copy the files, database and logs as they are now.
  2. Change every password and key stored on the server: the database password in wp-config.php, the security keys (salts), API keys for payments, email and other services, and the passwords for the control panel, FTP and SSH.
  3. Restore a backup from before 20 October, or clean the site properly by reinstalling WordPress, your plugins and theme from clean copies.
  4. On your own server, the safest route is a new server running patched PHP, with the site moved across. The attacker may have changed things outside the website.
  5. If the site stores personal data, the intrusion may be a breach you have to report to your data protection authority, which in Norway is Datatilsynet. The deadline under GDPR is 72 hours after you became aware of it.

For other symptoms, such as spam in Google and redirects, see signs that a WordPress site has been hacked.

Not the right answer?

Describe the problem to Howdy, and find the right article.