php2shell
Menu

WordPress site hacked after PHP2Shell: what to check

A defensive checklist for WordPress owners who suspect a break-in: signs to look for, WP-CLI checks, containment, cleanup order, and when to call an incident response firm.

Read this first

Vendors such as Cloudflare, watchTowr and Patchstack report attempts against the PHP2Shell flaws. CISA, BSI and CERT-EU have not confirmed exploitation, and the bug was not on CISA's Known Exploited Vulnerabilities list as of 21 October. So a break-in on your site is possible but unproven. This page helps you look.

An attack on a vulnerable PHP can happen before WordPress code runs, so WordPress and PHP logs may show nothing. Work through the checks below with one rule in mind.

No findings does not mean clean

Every check here can miss things. Checksum tools only know files from wordpress.org. An attacker with the right access can edit a log, hide a file or put a backdoor in the database. If nothing turns up and you still have a reason to doubt the site, treat it as compromised until a professional says otherwise.

If you have not yet patched PHP, do that first or in parallel. Cleaning a site that still runs a vulnerable PHP only invites the next break-in. See check your PHP version and change the PHP version.

Signs of compromise

Accounts

  • Administrator accounts you do not recognize, or an account created on or after 21 October.
  • Application passwords you did not create. In the dashboard: Users > Profile, scroll to Application Passwords. These let a script log in to the REST API without your password, and they survive a password change.
  • Changed email addresses on existing admin accounts.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user application-password list <user-id>

Run the second command for every user, not only admins.

Core and plugin files

wp core verify-checksums --include-root
wp plugin verify-checksums --all

The first compares core files against the official checksums. --include-root also warns about files in the site root that do not belong to WordPress. The second does the same for plugins, but only for plugins hosted on wordpress.org. Premium and custom plugins cannot be verified this way. Compare those against a fresh download from the vendor.

Treat a failed file as a lead to follow up. Some hosts and caching tools add files on purpose, so look at each one before you decide.

PHP files where there should be none

Uploads should hold images, documents and media. They should not hold PHP.

find wp-content/uploads -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)
find . -type f -name '*.php' -mtime -7 -not -path './wp-content/cache/*'

The second command lists PHP files changed in the last seven days. Updates produce hits too, so look for paths and names you would not expect.

Plugins you did not install

ls -la wp-content/mu-plugins wp-content/object-cache.php wp-content/advanced-cache.php wp-content/db.php

Must-use plugins in mu-plugins load on every request and do not appear in the normal plugin list. Many sites have none. The other three files are drop-ins. If you do not use object caching, page caching or a custom database layer, you should not have them.

Scheduled tasks

wp cron event list

Look for hooks that belong to no plugin you run, odd names, and events that fire every minute.

PHP and server configuration

Attackers like settings that run code on every request without touching WordPress files.

find . -name .htaccess -o -name .user.ini | xargs ls -la
grep -rn 'auto_prepend_file\|auto_append_file' . --include=.htaccess --include=.user.ini

An auto_prepend_file or auto_append_file line you did not add is a red flag. Check your host panel's PHP settings too, because the value can also be set there.

Other signs

  • Visitors report redirects, ads or pages you did not publish.
  • Search results show spam pages under your domain.
  • Your host sends an abuse notice or suspends the site.
  • Your mail server sends bulk mail you did not start.
  • Unexplained spikes in CPU, bandwidth or outbound connections.

What to do if you find something

Do these in order.

  1. Contain. Put the site into maintenance mode or take it offline at the host or DNS level. If the site handles payments or personal data, treat this as urgent.

  2. Keep evidence. Before you delete anything, copy the whole site (files and database) and the server logs to a place off the server. Do not edit the copy. An incident response firm, your insurer or a data protection authority may ask for it.

  3. Patch PHP. Move to a fixed build: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer. We recommend PHP 8.4.

  4. Rotate every credential. Change the passwords for all WordPress users, the database user (and DB_PASSWORD in wp-config.php), hosting panel, SFTP and SSH accounts, and any API keys stored in the site. Do it from a device you trust.

  5. Revoke application passwords. Delete the ones you cannot explain, or all of them:

    wp user application-password delete <user-id> --all

  6. Replace the salts. This logs out every session, including an attacker's.

    wp config shuffle-salts

  7. Reinstall from clean sources. Take core and plugins fresh from wordpress.org or the vendor. Do not reuse files from old backups:

    wp core download --force --skip-content
wp plugin install <plugin-slug> --force

    Reinstalling replaces files and nothing else. It leaves alone your uploads, mu-plugins, drop-ins, .htaccess, the database, or the accounts and cron events you found. Remove those by hand.

  8. Restore with care. A backup is only clean if it predates the break-in, and you may not know when that was. If you restore a backup, repeat every check on it.

  9. Watch afterwards. Re-run the checks after a day and after a week.

When to hire an incident response firm

Call in a professional if any of these apply:

  • You found a backdoor, a rogue admin account or an unexpected PHP file.
  • The site handles payments, health data or other personal data. You may have legal duties to report a breach, and the rules differ by country.
  • You run several sites on one account or server. One break-in can reach the rest.
  • You cannot say with confidence when the site was last clean.
  • The checks came back empty but something is still wrong.

We do not do forensics, and we do not name a specific firm yet. Recommendations explains what to look for. Ask for a written scope, what they will deliver and who keeps the evidence.

For a quick sort of your situation, use the triage guide. To confirm what your server runs, use the version check.

Last reviewed on 22 October 2026.