Was My Site Hacked by PHP2Shell? A Post-Patch Checklist

If your server ran an affected PHP version while PHP2Shell (CVE-2026-109618 and CVE-2026-109619) was public, use this checklist after you patch. It covers the checks a site owner can do without special tools, and points security teams to the vendors' detailed PHP2Shell detection guidance.

Step 1: Patch first

Checking for compromise on a server that is still vulnerable is wasted effort. Update PHP with the PHP2Shell patch guide or your distribution's fixed package, restart PHP-FPM and Apache, and confirm with the PHP2Shell checker.

Step 2: Decide whether you were exposed

Did the server run a PHP version older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12, without a vendor backport, between October 20 and your patch date?
Was it reachable from the internet, directly or through a CDN?
Was it behind a provider that had PHP2Shell rules active, such as Cloudflare (all plans) or WordPress.com hosting? That lowers, but does not remove, the risk.

If the answer to the first two is yes, continue with the checks below.

Step 3: Check accounts and files for PHP2Shell activity

Admin accounts: look for administrators you did not create in WordPress, Drupal, Joomla or your control panel.
New PHP files: list PHP files changed since October 20, especially in upload, cache and theme folders, where PHP files do not normally belong.
Scheduled tasks: review cron jobs and scheduled tasks for anything unfamiliar.
Plugins and themes: compare against what you installed. Remove anything you do not recognise.

find /var/www -name "*.php" -newermt "2026-10-20" -print

Step 4: Check the server

Unusual processes running as the web server user.
Unexpected outbound connections from the web server.
Unexplained PHP worker crashes or restarts around October 20 to 22, which the official disclosure lists as a reason to look closer.
Security events in your WAF or CDN dashboard. Hits on PHP2Shell rules are common scans and do not by themselves mean a compromise.

Step 5: Rotate secrets PHP2Shell may have exposed

PHP2Shell can expose data held in PHP's memory without leaving obvious traces. If you were exposed, rotate what that memory may have held:

Database passwords and application config secrets.
API keys for payment, email and cloud services.
Admin passwords, and session or salt keys (in WordPress, the salts in wp-config.php), which also signs everyone out.
TLS private keys, if PHP had access to them.

Step 6: If you find something

Take the site offline with a 503 page, or isolate the server.
Restore from a backup made before October 20, 2026, or rebuild the server.
Patch PHP before reconnecting, then rotate secrets again.
Tell your hosting provider, and check whether you have legal duties to report a breach of personal data.

Guidance for security teams

Detailed PHP2Shell detection guidance, signatures and log queries were published by security vendors for defenders:

Official PHP2Shell disclosure (investigation signals)
Cisco Talos (Snort rules)
Palo Alto Unit 42
CrowdStrike
Corelight (Zeek and Suricata)
Akamai
NCSC-NL repository

PHP2Shell "was I hacked?" FAQ

Can I prove my server was not hacked through PHP2Shell?

Not with certainty. The official disclosure says no single detection covers every path and that some attacks leave little trace. If the server ran an affected PHP version while exposed, treat secrets on it as possibly leaked and rotate them.

My hosting company says it is patched. Is that enough?

It covers the future, not the past. Ask your host when the fix was applied and whether they saw any incidents, then do the account and file checks on this page.

Should I rebuild the server?

If you find unknown files, accounts or processes, yes: restore from a backup taken before October 20, 2026 or rebuild, then patch before going back online.

Where can I find technical detection guidance?

Security vendors published detailed guidance and rules for security teams, including Cisco Talos, CrowdStrike, Palo Alto Unit 42, Corelight, Akamai and the Dutch NCSC. Links are below.