A patched PHP build is not proof that nothing happened. The PHP Foundation says it had not identified a working exploit when the 21 October release went public, and CISA added both CVE numbers to its Known Exploited Vulnerabilities catalog on 26 October. So treat this as a routine you run once, then again after any bad PHP security release. Seven signs cover most of it, and none of them needs a paid scanner. If one shows up, the order of the fix matters as much as the fix.
7 signs a compromise leaves behind
Each of the 7 signs has one place to look and one normal state to compare it against, and one sign is enough to keep looking. A sign only means something if you know what the site looked like before it appeared, since a check with no failure written down beforehand proves nothing, which is why most SEO tests cannot fail.
| Sign | Where to look | What normal looks like |
|---|---|---|
| New administrator | Users screen, filtered by Administrator | Accounts you created, on dates you remember |
| Redirect on phones or from search | Your site logged out on a phone, then a site: search | The page you expected, with no stop in between |
| PHP inside uploads | File Manager, wp-content/uploads | Images, PDFs and fonts. No .php files |
| Cron entry nobody added | Host panel cron list, or a cron plugin | The wp-cron ping your host set up |
| Theme files edited | File dates in wp-content/themes | Dates that match your last theme update |
| New outbound traffic | Access logs or the firewall log | Requests to your own services only |
| Spam in results | Search Console, Security Issues | Your own titles and your own pages |
Where to look in the accounts, the files and the logs
An administrator you did not create
Open Users, filter by Administrator, and count. On my blog the count was two on 22 October, my login and the editor login, both created in August, which is what I expect. That is the whole test. An account created last Tuesday, with an email address at a domain you have never heard of, is the one to look at. The registration date matters more than the display name, because an attacker will name the account something that looks like yours.
PHP files sitting among the images
WordPress never puts PHP files in wp-content/uploads. Open File Manager, go to that folder, and sort by type. A .php or .phtml file sitting next to the images is the file that usually serves the redirect or the spam page, and it often hides in a year and month folder created the same day. Delete it and check what created it.
A file date from a day nothing was updated
Theme and plugin files change when you update them, and those dates are fine. What should not happen is functions.php with a modified date from a day you updated nothing. Sort the theme folder by date modified, read the top ten entries, and match each one against your plugin and theme update history. An edited core file is the same signal, so run a checksum check on the WordPress core while you are there.
Access logs for the days the CVE numbers circulated
Your host keeps access logs, and they are the only record you cannot rebuild afterwards. Ask support for the logs for 20 to 23 October, the days the CVE numbers were circulating and the patches went out. Then read them for POST requests to PHP files inside uploads, requests to index.php with long query strings, and one IP hitting the same path hundreds of times in an hour. Any of those is worth a second look at the files behind them. Who was finding those bugs, and why the reports arrived that fast, is in how AI research changed PHP bug hunting.
Search results show spam the dashboard misses
Search Console has a Security Issues section, and it is empty on a clean site. Then search site:yourdomain.com and read the results as a stranger would. Spam pages that never appear in your dashboard still appear in search, usually with a title you did not write. If a page you did not publish ranks for your own brand, start with the uploads folder.
Recovery, in the order that stops a re-infection
- Patch the server first. If you have not confirmed your PHP number yet, start with how to check your PHP version. Cleaning a site on an open build just gives it back.
- Change four passwords. WordPress admin, hosting panel, database and SFTP. Then use the log out everywhere option, because a stolen session survives a password change.
- Replace the security keys. WordPress can generate a fresh set of salts, and pasting them into wp-config.php signs every user out of every session.
- Delete before you restore. Remove the unknown admin account and any PHP file in uploads first, or a restore from backup puts them straight back.
- Restore the code, keep the content. Replace core, theme and plugin files from a backup taken before 20 October if you have one. Your posts and uploads live in the database and the uploads folder.
- Ask for a malware scan in the same ticket as the logs. Most shared hosts run one free and will send the report.
- Tell Search Console if spam was served. Fix the site, then use Security Issues and request a review. The manual action clears once they confirm the cleanup.
- Watch for two weeks. A second re-infection usually means nobody found the way in.
If nothing shows up
Then you are probably fine, and the patched build did its job. Keep the backup current, keep the version number checked, and run the same seven checks after the next PHP security release. The week php2shell happened is worth reading once so the next one looks familiar. WordPress itself also said plainly that no WordPress update is required for this, which is unusual and useful to know when a plugin seller emails you about it.
CISA’s alert is the page to check before you believe anyone who says the danger has passed. It carries the SIGMA detection rule added on 23 October and the KEV listing added on 26 October.
More WordPress and hosting arguments sit in WordPress Care.
