Security
An update stops new attacks. It does nothing about files an attacker already wrote to your server. If your site was patched late, here is how to find out whether someone got in first.
Three weeks ago we wrote about CVE-2026-87902, the WordPress core flaw that attackers started exploiting within hours of the 7.1.2 fix. The advice then was simple: update now.
Most sites have updated since. The problem is that a lot of site owners now believe they are safe because they updated - and that is only half true. As a recent analysis on Cybersecurity Insiders puts it: "Your patch date only marks when the door closed. Whether anyone came through before then is what you need to answer."
A WordPress update replaces WordPress's own files with fixed versions. That is all it does. It does not look for, or remove:
.htaccess or wp-config.phpSo a site that was compromised on 23 September and updated on 1 October is now a patched, compromised site. The attacker no longer needs the vulnerability - they already have a way in.
And this was not a theoretical risk. The first probing was seen at 11:49 UTC on 22 September, and attempts to write files followed less than four hours later. Between 23 and 27 September, CrowdSec recorded more than 30,000 unique IP addresses sending matching requests, and CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 25 September.
You need to go through the steps below if all three of these were true of your site at any point after 22 September:
page-, such as page-templates.pearcmd.php.If you are not sure about points 2 or 3, assume they were true. Finding out you checked a clean site costs you an afternoon. Missing a backdoor costs a great deal more.
Do this first, today. Web server access logs are the only record of what happened during the exposure window, and on shared hosting they are often kept for only a few weeks. As the analysis warns: "Export your logs now, before September 22 rolls out of the window."
Download the access logs from your hosting control panel for 22 September up to the day you patched. Then search them for:
pearcmd.php. There is no legitimate reason for a WordPress site to receive these.cve-2026-87902-poc/1.0 and nuclei-cve-2026-87902/1.0, used by public exploit and scanning tools.Scanned is not the same as compromised. Almost every WordPress site on the internet will show some scanning in late September. What you are looking for is evidence that the vulnerable code ran, and then evidence that something was left behind.
The attacks that worked tried to write PHP files to places the web server can write to. Check:
/tmp and /var/tmp for any .php file. Files observed in real attacks include wp-pear-rce-flag.php and poc87902.php, and files starting with luci_ or zeta_.wp-content/uploads) for any PHP file at all. It should only contain images and documents.Do not rely only on those filenames. They are what has been seen so far; an attacker can call a file anything. The date and location of a file tell you more than its name.
Looking through folders by eye only finds what is obviously out of place. The reliable method is a comparison: "Download fresh copies of the same versions and compare. Anything added or changed outside an update is suspect."
In practice, that means:
wp core verify-checksums and wp plugin verify-checksums --all do this automatically for WordPress core and for plugins from the official directory.An attacker who gets code running usually sets up a second way in, so that patching the original hole does not lock them out. Check for:
wp-config.php, such as unfamiliar include lines or code at the very top or bottom of the file..htaccess, especially new redirect rules or rules that only apply to visitors arriving from search engines or on mobile.This step applies to every site that was exposed, whatever the earlier steps found: "Rotate the WordPress admin passwords, the database password and the security salts in wp-config.php. That cuts off any credentials an attacker may have copied."
An attacker who could run code could read wp-config.php, which holds your database password. Changing the salts also logs everyone out, which ends any session an attacker had open. While you are there, change the passwords for your hosting account and FTP or SFTP too.
Once you know what you are dealing with, there are two ways forward. The analysis draws the line clearly:
Clean the site in place when all you found were known dropped files and nothing suggests they actually ran. Remove them, rotate credentials and keep watching.
Rebuild from a known-good copy when you find signs that code ran, that persistence was added, or when your logs cannot answer the question. That means restoring from a backup taken before 22 September - or reinstalling clean copies of WordPress, your theme and plugins, and moving across only your content and uploads after checking them.
The tempting mistake is deleting the suspicious file you found and calling it done. If an attacker had code running, the file you found is rarely the only thing they left. When in doubt, rebuild. A half-cleaned site gets reinfected, usually at the worst possible moment.
One more thing to check after either route: Google Search Console. A compromised site can pick up spam pages or a security warning in search results, and you will want to request a review once it is clean.
Everything above is much harder than it needs to be on a site that was not set up for it. Four things turn a week of detective work into an afternoon:
This is the work our website maintenance and support service covers. If your site was unpatched after 22 September and you would rather not go through this checklist alone, get in touch. We will check the logs and files with you and tell you plainly whether the site needs cleaning, rebuilding, or nothing at all.
Need a hand with this? Orange Orbits builds and markets websites for businesses across the United States. Book a free 45-minute scoping call and we will give you a straight answer about your specific situation.
Keep reading
A critical flaw in the best-selling Avada theme lets an attacker take over a WordPress site with no login and no click. The fix has been out for weeks. Many sites still have not applied it.
Read articleThe third WordPress security release in a month fixes seven vulnerabilities, from stored XSS to SQL injection. Here is what each one means, and which sites should care most.
Read articleExploitation attempts against a WordPress core flaw started within hours of the fix shipping. The patch window is now measured in hours, and that changes how sites should be maintained.
Read articleBook a 45-minute call. We will ask about your goals, your constraints and your timeline, then send a written recommendation with real numbers. If we are not the right fit, we will tell you who is.
