Attackers Were Exploiting the Latest WordPress Flaw Within Hours. Here Is What to Check

On 22 September 2026 WordPress shipped version 7.1.2, a security release fixing a path traversal flaw in core. Within hours, security firm Field Effect was seeing attackers probe for vulnerable sites. By the next day those probes had turned into attempts to write files to servers.

If you run WordPress and your site is not on a patched version, this is the article to read today. If it already is, the more useful part is further down: what the speed of this campaign says about how WordPress sites need to be looked after.

What happened

The timeline, as reported by Field Effect:

• 17 September: WordPress 7.1.1 is released, fixing two separate issues publicised as Click2Shell and Comment2Shell.
• 22 September: WordPress 7.1.2 is released, fixing CVE-2026-87902, an unauthenticated path traversal flaw rated 9.2 on the CVSS scale. Exploitation attempts are observed within hours.
• 23 September: The activity moves from reconnaissance to file-creation attempts on sites that meet the conditions for exploitation.

Two security releases in five days is unusual for WordPress core, and it is exactly the situation in which sites fall behind: someone applies the first update, reasonably assumes the job is done, and misses the second.

The flaw, in plain terms

When WordPress displays a page, it works out which template file in your theme should render it. That is the page-template resolution step, and it has existed in roughly its current form for years - which is why the affected range stretches back to 4.7.0.

The flaw lets a specially crafted request push that lookup outside the active theme's folder, so WordPress loads a readable PHP file from somewhere else on the server. Loading the wrong PHP file is how a path traversal becomes something worse: if the attacker can reach a file that does something useful to them, they can get the server to run it.

No login is required. That is most of why the score is 9.2 rather than something lower.

Is your site exposed?

Not every WordPress site on an old version can be exploited. According to the published analysis, three things have to line up:

1. A vulnerable core version - anything from 4.7.0 up to, but not including, the fixed releases above.
2. A theme with a top-level folder whose name begins with page-, such as page-templates. This is a common convention, not an obscure one. Field Effect names Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney among the themes with this structure.
3. Particular server-side conditions that give the attacker a useful PHP file to reach.

On the third point, the attack traffic asks for pearcmd.php, a command-line script that ships with PHP's PEAR package manager. It is a well-known target in this kind of attack: on servers where PEAR is installed and PHP's register_argc_argv setting is on - as it is in some common PHP container images - including that file with the right parameters can be used to write a new file to disk. That lines up with the file-creation attempts seen on 23 September.

The honest summary is that exposure depends on your theme and your hosting, and working out whether both conditions hold takes longer than applying the update. So do not try to reason your way out of patching. Patch, then investigate.

What the attack traffic looks like

Whether or not you were exposed, it is worth knowing whether anyone tried. The indicators Field Effect highlights are distinctive enough to search for in your web server access logs:

• Requests carrying both page_id and pagename parameters at once. Normal WordPress links use one or the other.
• Double-encoded traversal strings such as %252e%252e - an encoded .., encoded twice to slip past simple filters.
• References to page-templates or similar theme folder names in the query string.
• Requests for pearcmd.php, which has no business being requested on a WordPress site.

Hits on these from 22 September onwards mean your site was scanned. That alone is not a compromise - almost every WordPress site on the internet will have been scanned this month. What matters is whether anything changed on disk afterwards.

What to do this week

In order:

1. Update core to a fixed release. 7.1.2 if you are on the current branch; 7.0.6, 6.9.9 or 6.8.10 if you are pinned to an older one. Check the version in the dashboard afterwards rather than assuming an automatic update ran - hosts and security plugins sometimes disable them.

2. Check your active theme for a page- folder. If it has one, treat the site as having been in the exposed group until you have shown otherwise. Child themes inherit from their parent, so check both.

3. Search your access logs for the patterns above, from 22 September to the time you patched.

4. Look for new PHP files in writable locations. Field Effect recommends monitoring /tmp, /var/tmp, the WordPress document root and other web-writable folders. The uploads directory deserves particular attention: it should contain images and documents, never PHP. Any PHP file created there recently is a strong signal something has gone wrong.

5. If you find something, stop and escalate. Do not just delete the file and move on. A file that was written once can be written again, and the first thing most attackers do is leave a second way back in. Take a backup of the current state for investigation, restore from a known-clean backup taken before 22 September, patch, then rotate every password and key the site holds - admin accounts, database credentials, and the salts in wp-config.php.

The patch window is now hours

The detail in this incident worth remembering is not the CVE number. It is the gap between the fix being published and the first exploitation attempt: a matter of hours.

That is how it works now. A security release is, among other things, a public description of what was wrong. Attackers compare the patched code with the previous version, work out the flaw, and start scanning - and with automated tooling, that turnaround keeps shrinking. For a platform that runs a very large share of the web, a working exploit is worth building immediately.

The consequence for site owners is uncomfortable. The traditional approach - an agency or freelancer applies updates once a month, or when someone remembers - leaves a site exposed for days or weeks after a flaw is publicly known. Weeks used to be survivable. Against a campaign that starts the same afternoon, it is not.

A maintenance process that keeps up

None of this requires anything exotic. It requires a process that someone actually owns:

• Automatic minor and security updates switched on for core, with someone checking that they applied. They are on by default in WordPress; they are also frequently switched off and forgotten.
• A staging copy of the site, so major updates can be tested before they reach production. The fear of an update breaking the site is the most common reason updates get postponed, and staging removes it.
• Daily off-site backups with a tested restore. A backup nobody has restored from is a hope, not a backup. Keep enough history to go back further than your detection time.
• File-change monitoring on the document root and uploads folder, so a new PHP file raises an alert rather than being discovered months later.
• Less to patch. Every unused plugin and theme is attack surface with no benefit. Remove, rather than deactivate, what you do not use.
• A security feed someone reads. Two core security releases five days apart is the kind of thing that only gets caught by a person paying attention.

This is the work our website maintenance and support service exists to do, and it is part of every site we build through our WordPress development practice. If you are not sure which version your site is running, or whether its theme has a page- folder, get in touch and we will check it with you.

Whoever looks after your site, the question to ask them this week is simple: which version of WordPress is it on right now, and when did that change? If the answer takes more than a minute to find, the process needs work before the next security release, not after it.

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.