Was My Site Hacked Before I Patched PHP2Shell? How to Check and What to Do

By Umair Ali Sadaqat · Updated · Editorial policy

Exploit attempts began before the Black October patch was public, so patching may have closed the door after someone walked in. A calm, ordered checklist for spotting a compromise and recovering from one.

Patching PHP stops new attacks through the Black October flaws. It does not remove anything an attacker installed before you patched. 404 Media reported that Cloudflare saw exploit attempts in the hours before the 21 October disclosure, and Amazon reported attempts before it too. So a quick check is worth an hour of your time, even though most sites that were probed were not successfully broken into.

An honest caveat: the PHP advisory does not publish a list of indicators of compromise. The checks below are the standard ones for any PHP code-execution attack. They catch the common follow-ups (a web shell, a new admin account, injected scripts), not every possible trick.

First: preserve, do not panic-delete

If you find something, the instinct is to delete it immediately. Copy it first. Download the suspicious file, export the logs and note the timestamps. You may need them to understand how far the attacker got, and your host or payment provider may ask for them.

1. Look at web server logs around 20 to 23 October

In your access logs, look for:

  • Unusually large POST requests, or many POSTs to URLs that normally only receive GETs.
  • Multipart upload requests to pages with no upload form.
  • Requests to .php files you do not recognise, especially inside upload folders.
  • A burst of 500 errors or PHP fatal errors in the error log in that window.

On shared hosting, cPanel's Raw Access and Errors pages give you these logs.

2. Look for unexpected PHP files

The usual payload after code execution is a "web shell": a small PHP file that lets the attacker come back later. Look for:

```bash

PHP files changed in the last 10 days under the web root

find /path/to/site -name "*.php" -mtime -10 -ls

PHP files where there should be none

find /path/to/site/uploads /path/to/site/images -name "*.php*" ```

Attackers sometimes fake file dates, so a clean result here is good news, not proof. If your site is deployed from Git, git status and git diff on the server show anything that changed outside a deployment, which is far more reliable.

3. Check accounts and access

  • Administrator accounts in your CMS that nobody on your team created.
  • New FTP or SFTP accounts, SSH keys in ~/.ssh/authorized_keys, and new database users.
  • Scheduled tasks: crontab -l for each user, and the Cron Jobs page in your hosting panel.

4. Check what visitors see

Load your site in a private window and on a phone. Look for redirects to other sites, pop-ups, or new script tags in the page source pointing to unfamiliar domains. In Google Search Console, check Security issues and Manual actions. If you run a store, inspect checkout pages specifically.

5. Check outbound activity

A compromised server often starts sending spam or attacking others. Signs include a sudden jump in outgoing mail, CPU or bandwidth; unknown processes in top or ps aux; and warnings from your host.

If you find evidence of compromise

  1. Take the site offline or into maintenance mode if it is serving anything harmful to visitors.
  2. Restore from a backup made before 20 October 2026, onto a server running a fixed PHP. Cleaning a live server file by file is error-prone; a known-good restore is safer.
  3. Rotate every secret the server held: database passwords, CMS admin passwords, API keys in config files, payment gateway keys, SMTP credentials, and any cloud access keys.
  4. Re-apply only the content changes made since the backup, carefully, by hand.
  5. Tell the people who need to know. If personal data may have been accessed, check your legal duties; in many places, breach notification rules have deadlines. If card data could be affected, contact your payment provider.
  6. Write down what you did and when.

If you are not confident doing this, a professional incident response service or your host's security team is worth the money.

If you find nothing

Good. Keep the logs from the window anyway, confirm you are on a fixed PHP using the version guide, and make sure you have regular off-server backups so a restore is easy next time.

Move your site to WeInc

A rebuild on a platform you do not have to patch is one way to start clean after an incident. Move your site to WeInc: first month free with code BLACKOCTOBER, until November 21, 2026. New customers only. Claim the offer

More in Blog

Start building

How we research, test and update this page: our editorial policy. We.Inc is our own product.

Product

Who It's For

Features

Resources

Company

View Sitemap