Check if your website is hacked after PHP2Shell

Are there official indicators of PHP2Shell compromise?

No definitive PHP2Shell-specific indicator list has been published by PHP as of 22 Oct 2026. In a monitoring thread on X, the Wiz researchers suggested watching for unusual multipart requests followed by memory-limit errors or HTTP 500 responses, malformed PHPSESSID session cookies and PHP workers restarting unusually often. Several national agencies also advise checking for backdoors. Treat these signs as leads to investigate, not proof. The checks below look for the usual signs of a website takeover.

What should I do before checking?

Install the PHP2Shell patch and restart PHP. Checking a site that’s still vulnerable only tells you about the past. If you see active damage (defacement, spam, redirects), take the site offline first.

How do I check if my website is hacked?

Look for changes you didn’t make:

1. Admin users you don’t recognise. In WordPress, open Users and filter by Administrator. Check hosting, FTP/SFTP and database accounts too.
2. PHP files where they don’t belong. Upload folders such as wp-content/uploads should hold images and documents. A .php file there is a strong warning sign.
3. Recently changed files you didn’t touch. Sort files by modified date in your file manager; look closely at anything changed since the vulnerabilities were announced.
4. Plugins, themes or must-use plugins you didn’t install. Check the wp-content/mu-plugins folder, which doesn’t appear in the normal plugin list.
5. Scheduled tasks you didn’t create. Check cron jobs in your hosting panel; attackers use them to reinstall backdoors.
6. Warnings from outside. Alerts from your host, security issues in Google Search Console, or reports of spam or redirects from your domain.
7. Logs, if you have them: unusual requests, error spikes or crashes around the disclosure period.

Is an unfamiliar PHP file proof of PHP2Shell?

No. An unexplained file, account or redirect is evidence of a problem, not of which vulnerability caused it. Investigate it either way.

What do I do if I find something?

Act in this order, and keep a copy before you delete anything:

1. Take the site offline or block public access.
2. Preserve evidence: copies of suspicious files, logs and a snapshot, with times noted.
3. Change every password from a clean device: hosting, FTP/SFTP, database, every admin account, and the site’s secret keys and API tokens.
4. Restore from a backup made before the intrusion, or rebuild from trusted sources, then update PHP, the application, themes and plugins before going live.
5. Tell your host, and anyone you’re obliged to notify if personal or payment data may be involved.

Does installing the patch remove an attacker?

No. The patch closes the hole; it doesn’t remove a backdoor, a rogue account or stolen credentials. Because the research also describes memory disclosure, a clean file check doesn’t rule out data exposure either.

Should I get professional help?

Yes, if the site handles payments or personal data, if you can’t find a clean backup, if the problem returns after cleaning, or if you’re unsure how far the intrusion went. Professional incident response can scope the damage properly.

Was my site hacked just because PHP was vulnerable?

Not necessarily. Cloudflare reported attack attempts, but successful compromise has not been confirmed in the sources we checked as of 22 Oct 2026. That doesn’t prove your site is clean either. Check, don’t assume. Back to the PHP2Shell checker.

Which sources support this page?

• Wiz Research: monitoring guidance (X thread)
• Wiz Research: original research
• CISA: incident and vulnerability response playbooks
• CISA/FBI: advisory with web shell defense guidance
• The PHP Group: security advisory
• Cloudflare: WAF protections