TL;DR: Updating to WordPress 7.1.2 closed CVE-2026-87902, but it didn’t remove anything attackers wrote to your server before you updated. If your site was exposed, check /tmp, your logs from the exposure window and your admin accounts. Then decide whether to clean the site or rebuild it.
It’s Tuesday, September 22, and the WordPress security release shows up in your dashboard. You click update on the company site between two meetings and close the ticket. Done. Except the first attack attempt against this flaw was logged that same morning, and within four hours attackers were trying to write their own files onto servers. Your update locked the door, but it did nothing about anyone already inside.
That gap is the problem. WordPress fixed CVE-2026-87902 on September 22, and most teams treated it as routine maintenance. But this attack could drop PHP files on disk, and updating WordPress doesn’t delete them. Here’s how to tell whether you were exposed, where to look, and how to decide between cleaning a site and rebuilding it.
Were you exposed?
You were exposed if your site ran an unpatched version after September 22 and all three conditions below were true. If any one is false, the known attack path doesn’t work.
According to Patchstack’s analysis, exploitation needs all of these:
- An unpatched WordPress version. The fix shipped in 7.1.2 and was backported to every branch back to 4.7, so “unpatched” means anything that didn’t take the September 22 update.
- A theme folder starting with page. The active theme or its parent has a top-level directory whose name begins with page-, such as page-templates.
- A usable PHP file on the server. A local PHP file the attacker can pull in has to be readable by the web server. The public attacks used PEAR’s pearcmd.php.
The flaw needs no login, so anyone on the internet could try it.
Quick check: Open your active theme’s folder and look for a directory that starts with page-. It takes two minutes, and it tells you whether the rest of this article applies to you.
Why patching fast wasn’t enough
Attackers went from probing to writing files in under four hours on day one. A site patched the next morning may already have been hit.
Patchstack’s timeline records the first activity at 11:49 UTC on September 22 and file-writing attempts by 15:34 UTC the same day. After that, the scanning went wide. CrowdSec counted 30,813 unique IP addresses sending matching requests between September 23 and 27, which points to automated tooling scanning broadly. CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 25.
Your patch date only marks when the door closed. Whether anyone came through before then is what you need to answer.
What to check, in order
Start with the files this campaign is known to write, then read your logs for the exposure window, then look for the footholds attackers commonly leave after they get code running.
- Known file locations. Look for unexpected .php files in /tmp and /var/tmp. Files seen in the wild include wp-pear-rce-flag.php, poc87902.php, and names starting with luci_ or zeta_. Also look for any new PHP file in the web root dated after September 22.
- Logs for your exposure window. Search from September 22 to your patch date for requests mentioning pearcmd.php, and for the user agents cve-2026-87902-poc/1.0 and nuclei-cve-2026-87902/1.0. Patchstack notes that a normal page URL returning a 200 response with RSS or OPML content means the vulnerable code path was reached. Treat that as confirmed exposure, not a blocked attempt.
- Core, theme and plugin files against clean copies. Download fresh copies of the same versions and compare. Anything added or changed outside an update is suspect.
- Footholds. Not confirmed for this campaign, but typical once attackers can run code: new or changed administrator accounts, unrecognized scheduled tasks in WP-Cron or the server’s cron, and edits to wp-config.php or .htaccess.
Watch out: Log retention on shared hosting can be short. Export your logs now, before September 22 rolls out of the window.
Clean or rebuild?
Clean the site in place when your findings are limited to known dropped files and nothing suggests they ran. Rebuild from a known-good copy when you find signs that code ran, persistence was added, or your logs can’t answer the question.
Whichever column you land in, 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.
Frequently asked questions
Does updating WordPress remove malware?
No. The update replaces WordPress’s own files. It doesn’t delete files an attacker added elsewhere, such as PHP files in /tmp or new admin accounts.
How do you tell if a WordPress site has been hacked?
Look for PHP files you didn’t add, admin accounts nobody created and scheduled tasks you don’t recognize. For this flaw, start with /tmp, /var/tmp and your logs from September 22 to the day you patched.
The lesson for next time
An update only protects you from the day you apply it. Next time a critical WordPress release ships, note your exposure window the moment you patch: release date, patch date, and which sites sat in between. That one note turns a week of guessing into an afternoon of checking.
______
Author bio
DeShea Witcher handles partnerships at Guardian Gaze, an AI-powered WordPress malware scanner and website security monitoring platform that runs its analysis outside the site. It looks for malicious code, suspicious file changes, compromised plugins and themes, and other indicators of compromise. He writes about how small and mid-sized WordPress sites get compromised and how teams recover. guardiangaze.com/wp
Join our LinkedIn group Information Security Community!
