Was my site exploited via PHP2Shell? Indicators to check

Check for PHP2Shell compromise by looking back to 17 October 2026, the date AWS saw the first exploitation attempt, not just to the 21 October disclosure. Patching stops new attempts and removes nothing already planted. If your PHP was unfixed and reachable in that window, review logs, new files, accounts and scheduled tasks, then rotate the secrets your PHP user could read.

The fix itself is covered in the PHP2Shell overview and the patch and restart guide. This page starts after the patch and answers the question those pages leave open.

Was my site hit before I patched?

Nobody outside your server can tell you yet. What exists is a record of attempts. We found no primary source that names a compromised site, and the sources disagree on how much activity there has been.

Read that as "attempts yes, confirmed victims unpublished". The UK NCSC takes the cautious side of it: for systems that could not be updated at once, assess for compromise and look for backdoors before patching. Absence from the public record is a statement about reporting. It says nothing about your server.

How far back should I look?

Start on 17 October 2026. That is the earliest attempt AWS reports, and AWS advises investigating from that date, not from the disclosure. The window ends when the PHP workers serving the site were restarted on fixed code, which is the timestamp your host or your service manager can give you.

If you keep logs for longer, a wider net costs little. Sophos recommends reviewing from 1 August 2026. That date comes from Sophos's own framing and has no incident behind it in the sources we read, so treat it as a cautious option for teams with the retention to support it.

Logs may not reach back that far, or may never have held what you need. Sophos points out that many CDN and access logs do not record request bodies, and the PHP project's own advisory says clean logs do not prove safety. If the logs are thin, say so in your notes, because that gap is a finding too.

What are the indicators of compromise?

No source we read publishes a definitive file signature for PHP2Shell. The list below comes from the vendors that wrote hunting guidance. SentinelOne says these are leads, not verdicts, because memory errors and HTTP 500s also occur on healthy servers.

Wordfence, in a post republished on Malware News, lists file names seen in public proof-of-concept code, including wp2s.php, php2shell.php and axiom_*.php. Searching for them is cheap. A miss means little, because an intruder who read that list would pick a different name.

A separate WordPress incident overlaps the dates. Patchstack's alert describes attackers using stolen UpdraftCentral keys to install backdoors on connected sites. It is not part of PHP2Shell, so check for it on its own. If you run that plugin, what to do about the exposed UpdraftCentral keys has its own page.

Do I need to rotate passwords and keys?

No primary source requires a blanket rotation after patching, and none rules it out. Two facts drive the decision. Code execution as the web worker account reads whatever that account can read, which usually includes the database password and API keys in your config. And Wiz reports a path that can read worker memory without running code, which Patchstack takes as a reason to rotate credentials the server holds. The PHP advisories themselves describe code execution only.

What to rotate, in the order that limits damage:

• Database user and password used by the site, then update the config that holds them.
• Payment, email, storage and third-party API keys the site uses.
• Hosting panel, SFTP, SSH and CMS admin passwords, and any API tokens for the host.
• WordPress authentication keys and salts, which also logs out every session.
• Application signing and encryption secrets, after checking what breaks. Rotating a framework key can invalidate sessions or stored encrypted data.
• TLS private keys if the server held them. Sansec lists them among the secrets the memory disclosure path can expose.
• Review the use logs of each old key for the window, then revoke it.

Never put a new secret onto a server you have not yet cleaned or rebuilt. Rotation limits what an intruder can do with old keys. It does not evict an intruder who is still on the machine.

What do I do if I find something?

Treat the whole host as compromised and plan for more than one bad file. The steps follow the WordPress.org hacked site guide and watchTowr's advice to preserve logs and files first.

• Write down what you saw, with times and time zone.
• Copy PHP, web server and WAF logs and the suspicious files somewhere off the server before you change anything.
• Take a snapshot of the whole site, even though it is infected.
• Patch PHP and restart the workers, so the same door is shut.
• Rebuild from known-good sources or restore a backup older than the earliest sign, onto the patched runtime.
• Reinstall CMS core, plugins and themes from official packages, and compare the rest against a known-good copy.
• Remove unknown admin users (finding a hidden WordPress admin is harder than it sounds), cron entries, scheduled tasks and SSH keys.
• Rotate secrets as above, from a trusted machine.
• Set session.upload_progress.enabled=0 if you do not use that feature. The PHP project's 23 October notice recommends it until the next bugfix release, which also covers CVE-2026-115560.
• If you cannot do this with confidence, the UK NCSC recommends an assured incident response provider.

Questions for your host belong in a message you can forward. Send this one:

For [your domain], please send the web server and PHP error logs from 17 October 2026 to now, and tell me how far back your retention goes. Please also give the time the PHP workers serving it were restarted on a fixed package, and say whether you saw any PHP file changes, new accounts or scheduled tasks on my account in that period.

More on what a host can and cannot confirm is in what a host can confirm about PHP2Shell, and on who owns which step in who owns patching on shared hosting.

Am I affected? A three-state self-test

Why doesn't patching remove an intruder?

A patch changes the PHP engine from the moment the workers restart. A web shell, a new admin account or a cron entry added on 18 October is ordinary data on disk and in the database, and the new engine runs it as before. The PHP project calls updating the only complete fix for the flaws, and says nothing about cleaning up after them.

That is also why a restore can disappoint. A backup made after 17 October may carry whatever was planted, so choosing a clean restore point matters. A backup restored onto an unpatched server leaves the original hole open. The order that holds up is patch and restart, restore or rebuild from before the earliest sign, then rotate. The 10 minute response covers the patch side, and the tracker lists the other incidents this month that need their own checks. The rest of the incident response guides cover cleanup in more depth.