Hacked Through PHP2Shell? Signs of Compromise and What to Do Next

By Glenn Lyvers · Updated October 24, 2026 · 6 min read

Here is the uncomfortable part of PHP2Shell: the first recorded exploitation attempt was on October 17, 2026, four days before the fix was released. Almost nobody could have patched in time. If your server ran a vulnerable PHP build after that date, the honest question is not only “am I patched now?” but “did anyone get in before I patched?”

Patching closes the door. It does nothing about a backdoor that is already installed. Attackers who get remote code execution almost always leave a way back in, and they often wait weeks before using it.

What an attacker could have done

PHP2Shell runs the attacker’s code as your web server’s user. That account can usually write to your site’s files and read its configuration, which means an attacker could have read your database password from wp-config.php or .env, added files anywhere the site can write, created admin accounts through the database, and planted scheduled tasks that reinstall malware after you clean it.

Signs in your files

• PHP files where they do not belong, especially in wp-content/uploads, cache folders or image directories. See PHP files in the uploads folder.
• Files modified after October 17 that you did not change. Sort by modification date, and remember that attackers sometimes fake timestamps; my guide on timestamp forensics covers how.
• A changed .htaccess with new redirect or auto_prepend_file lines.
• Obfuscated code: long base64 strings, eval(, gzinflate( or str_rot13( chains in theme or core files.

Signs in accounts and settings

• Admin users you do not recognize, including ones hidden from the user list. See hidden admin users.
• New cron jobs in your control panel, or unfamiliar entries in WordPress’s scheduled tasks.
• New SSH keys or FTP accounts you did not create.
• Plugin or theme files that differ from the official versions. A WordPress core checksum check (wp core verify-checksums) is a fast first pass.

Signs in how the site behaves

Visitors redirected to spam or scam pages (often only on mobile, or only from Google), your host warning about outbound spam or high CPU, Google Search Console security warnings, strange pages in search results, or an antivirus vendor suddenly blocking your domain. Any one of these after October 17 on an unpatched server should be treated as a compromise until proven otherwise.

What the logs can tell you

Look at your web access logs from October 17 onward for unusual requests followed by requests to files that did not exist before, and check error logs for PHP out-of-memory errors at odd times, since one of the two flaws is triggered through memory exhaustion. Unfortunately, the most dangerous version of the attack can look like an ordinary request, so a clean-looking log is not proof of a clean server. File and account checks matter more.

If you find something

1. Patch first if you have not, so the attacker cannot simply walk back in. See how to upgrade PHP.
2. Do not just delete the obvious file. Backdoors come in sets, and the one you find is rarely the only one.
3. Rotate every secret the server held: database password, WordPress salts, API keys in config files, and hosting, FTP and SSH passwords.
4. Clean properly, then watch the site for reinfection. My first steps after a hack guide sets out the order.

If you want both jobs done at once, my $195 emergency PHP2Shell upgrade includes a check for signs of compromise. If I find that someone already got in, I will show you the evidence and you can decide whether to move to a full Bulletproof Cleaning.

Common questions

If I patch PHP now, am I safe from PHP2Shell?

You are safe from new attacks through PHP2Shell, but patching does not remove anything an attacker installed before you patched. Exploitation attempts began on October 17, 2026, so check for backdoors, unknown admin users and new cron jobs as well.

What does a PHP2Shell compromise look like?

Usually like any other server hack: new PHP files in uploads or cache folders, modified .htaccess files, unknown admin accounts, new cron jobs or SSH keys, spam redirects, and host or Google warnings.

Do I need to change passwords after PHP2Shell?

If your server ran an unpatched PHP build after October 17, 2026, yes. Rotate the database password, WordPress salts, API keys stored in config files, and your hosting, FTP and SSH credentials.

Can my security plugin detect a PHP2Shell attack?

Not the attack itself, because it runs before WordPress and its plugins load. A file scanner may catch what the attacker left behind afterward, but heavily obfuscated backdoors are often missed.

Will restoring a backup undo a PHP2Shell hack?

Only if the backup is from before the compromise and you patch PHP and rotate every credential first. Otherwise, you restore the backdoor or leave the door open for the attacker to come straight back.