Every WordPress Since 4.7 Was Vulnerable. Three Conditions Decide If Your Shop Was Reachable (CISA Deadline: Sept 28)

There is a specific kind of quiet that settles over a small shop’s website. Nobody logs into it. Nobody looks at it. It takes the contact form submissions, it shows the hours, it holds the eight product pages, and for months at a time the only person who touches it is the bot that renews the TLS certificate.

That quiet is the point. You paid someone once, it works, you moved on. That was the correct decision.

It also means that when WordPress shipped an emergency security release on September 22 that patched every version of itself going back to 2016, there was no human in your building who noticed.

Note: WordPress 7.1.2 landed September 22, 2026 — five days old as of September 27. The first exploitation attempt was recorded the same day. CISA’s federal patch deadline is September 28, which is tomorrow.

The good news, and it is real news, is that most WordPress sites fixed themselves overnight without anyone asking them to. The bad news is that the reasons a site doesn’t auto-update are boring, invisible, and absurdly common in exactly the kind of install a 3-to-10-person business ends up with — a site a contractor built in 2019, moved to a cheap host in 2022, and hardened slightly in 2023 by adding two lines to wp-config.php that nobody wrote down.

This piece is the triage. Not “patch now” — you already know that. The useful parts are: how to tell in twenty minutes whether your site was actually reachable versus merely running a vulnerable version, the exact strings to grep in your access logs to find out if someone already tried, and the eight specific configurations that silently turn off the auto-updater you’re relying on.

What actually broke: a validation check that existed three lines away

The bug is CVE-2026-87902, tracked upstream as GHSA-7hp8-65ch-5whp, classified as CWE-98 (improper control of filename for include statement), and scored 9.2 critical on CVSS v4.0. It was reported responsibly by Robert Ressl. The fix release was led by John Blackbourn with contributions from more than thirty people, which tells you something about how fast this was assembled.

It lives in wp-includes/template.php, inside get_page_template(). That function is how WordPress decides which theme file renders a page. If you have a page whose slug is contact, WordPress will happily look for page-contact.php in your theme before falling back to page.php and then singular.php. That’s a feature every theme in existence depends on.

The function builds a candidate filename by string-concatenating the pagename query parameter: "page-{$pagename}.php". There are two code branches that feed this lookup. One of them — the one that handles an explicitly assigned page template slug — runs the input through validate_file(), WordPress’s own guard against directory traversal. The other branch, the one building from pagename, did not. And somewhere in the request-handling path, an urldecode() call turns percent-encoded traversal sequences into real ones.

Patchstack’s write-up puts it in the only sentence that matters: “The protection existed three lines above the place it was missing.”

So an unauthenticated GET request with a carefully shaped pagename value can walk out of the theme directory and make WordPress include() any .php file on that server that the web user can read. No login. No user interaction. No plugin required. Core.

The version range is the part that made everyone’s Tuesday worse: 4.7.0 through 7.1.1. That is effectively the entire history of WordPress anyone is still running. The project backported the fix to every branch still eligible for security updates — 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, and onward down through 4.7.37, roughly two dozen point releases shipped simultaneously.

The 7.1.2 fix does two things, and it’s worth knowing both because they tell you how the maintainers rated their own confidence. First, they added the missing validate_file() call. Second, they added a new containment function that requires every resolved template path to end up inside a designated theme directory regardless of how it was derived. That second one is a belt-and-suspenders structural fix — the kind you write when you suspect the first fix only closes the door you happened to find.

”Vulnerable” and “exploitable” are not the same word here

This is where most of the coverage stops being useful, and where you can actually save yourself a panic.

Getting from “include an arbitrary local .php file” to “attacker runs code on my server” requires additional conditions to line up. Three of them, per Patchstack’s analysis:

If all three are true, an unauthenticated request becomes a webshell. If only some are true, you are in a much better place — but you are not in a safe place, and I want to be precise about why.

Even without a code-execution gadget, an arbitrary-local-file-include still lets someone make your site execute PHP files it was never meant to execute. Depending on what’s installed, that can mean triggering installer routines, provoking verbose errors that leak paths and database names, or hitting a bundled script that does something side-effectful. The absence of pearcmd.php removes the best-known path to a shell. It does not make the bug harmless.

So the honest framing: conditions 1 through 3 tell you how bad an unpatched window was, not whether you can skip patching.

The twenty-minute exposure check

If you have SSH or a file manager and you want a real answer rather than a vibe:

# 1. What version are you actually on?
#    Don't trust the admin dashboard if you suspect a caching plugin.
grep "wp_version = " wp-includes/version.php

# 2. Which theme is actually active? Don't go by the folder you remember.
wp option get template    # the parent theme
wp option get stylesheet  # the child theme, if there is one — often different
#    No WP-CLI? Read the 'template' and 'stylesheet' rows out of wp_options.

# 3. Does EITHER of those have a page-* top-level directory?
#    Check both. get_page_template() looks in the child theme and then falls
#    back to the parent, so a tidy child theme sitting on top of a parent that
#    ships page-templates/ is still a hit.
ls -d wp-content/themes/CHILD-THEME/page-* wp-content/themes/PARENT-THEME/page-* 2>/dev/null

# 4. Is register_argc_argv on?
php -i | grep register_argc_argv
#    (on shared hosting, make a one-line phpinfo() file, read it, then DELETE it)

# 5. Does pearcmd.php exist and is it readable?
ls -l /usr/local/lib/php/pearcmd.php /usr/share/php/pearcmd.php /usr/share/pear/pearcmd.php 2>/dev/null

Six commands. If step 1 shows a patched version and steps 3–5 come back empty, you had a narrow window and a narrow exposure, and you can move on to the log check with a lower heart rate.

The child-theme step is the one people get wrong, and it’s worth dwelling on for a second, because it’s the difference between a real answer and a reassuring one. Small-business sites are disproportionately built as child themes — that’s the correct way for a contractor to customize a commercial theme without losing their work on update. The child theme is usually four files and a stylesheet. It will almost never contain a page-templates/ directory. The parent, which is where the actual theme lives, very often does. Check the folder you didn’t build.

If you genuinely can’t patch before the deadline

Sometimes the answer is “I can’t tonight.” A plugin that breaks on the newer branch. A host that owns the version number. A developer who built the site and isn’t reachable until Monday. The federal deadline is tomorrow, the exploit is public, and you are stuck.

The useful property of those three preconditions is that they are ANDed. The published exploit chain needs all three to line up. You only have to take one away, and every option below is faster than a core upgrade:

Do one or two of these and you have bought yourself the weekend.

What you have not done is fix the bug. You’ve pulled out the rungs that the currently-circulating tooling climbs. Remember that the 7.1.2 release contained two fixes, not one — the missing validate_file() call and a new structural containment check that forces every resolved template path to land inside a real theme directory. Maintainers don’t write the second kind of fix unless they suspect there are other ways up that nobody has published yet. Mitigate tonight if you must. Patch as soon as the plugin conflict is sorted.

The timeline is the story: patch to weaponized in one business day

Here’s what the exploitation curve actually looked like, assembled from Patchstack’s telemetry and The Hacker News’ reporting on it.

The three-stage pattern is textbook and worth internalizing because you’ll see it again on the next one:

1. Confirm the primitive. Include a file that definitely exists and is definitely harmless. If the page renders differently, the bug is live.
2. Find the gadget. Probe all three common pearcmd.php locations with +config-show to see which one answers.
3. Write the shell. Use +config-create to drop a .php file into /tmp or /var/tmp, then include that.

A representative request, reconstructed from the reporting:

GET /?page_id=<a valid page id>&pagename=templates%2f<traversal>usr%2flocal%2flib%2fphp%2fpearcmd&+config-show

Dropped filenames observed in the wild included wp-pear-rce-flag.php, poc87902.php, and randomized variants matching luci_*.php and zeta_*.php. Some requests pulled additional PHP upload scripts from GitHub to establish persistence beyond the first shell.

Source addresses reported include 104.194.9.227 (New Jersey), plus 43.250.53.42, 180.251.159.243, 195.178.110.247, 107.189.14.87, 45.61.184.170, and 92.246.130.76. Blocking those IPs is not a defense — it’s a rounding error against a bug with a public Nuclei template — but they’re useful as a retrospective search term.

Grep your logs. This is the part almost nobody does.

Patching tells you you’re safe going forward. It tells you nothing about the window between September 22 and whenever your site actually updated. If that window was hours, fine. If it was days because your auto-updater was off, you need to know whether anyone walked through.

The signature here is unusually clean, which is a gift. Pull your access logs for September 22 onward and look for:

A starting point on most Apache/nginx setups:

zgrep -iE 'pagename=[^&]*(\.\.|%2e%2e|%252e%252e)|pagename=[^&]*templates(/|%2f)|pearcmd|(\+|%2b)config-(show|create)' \
  /var/log/nginx/access.log* | less

Note the alternations for the unencoded forms — plain .., a literal /, a literal +. The published proof-of-concept percent-encodes its traversal, and if you copy the reconstructed request out of the write-ups and grep for exactly that, you’ll build a pattern that only catches people using the PoC verbatim. Nothing obliges an attacker to encode a query string at all. nginx and Apache both log the request line as it arrived, so you have to search for every spelling that works, not just the famous one. A narrow grep that returns nothing is worse than no grep, because it returns nothing and you believe it.

What a hit actually means. A matching line tells you someone sent the request. It does not tell you the request worked. Most of the traffic in Patchstack’s telemetry was observed and blocked, and a request aimed at a site whose theme has no page-* directory was never going anywhere regardless. Mass scanners spray the entire IPv4 space; being sprayed is not being breached. So treat a log hit as “confirmed targeted, exposure unknown” and go straight to the next check, which is the one that distinguishes an attempt from a result:

find /tmp /var/tmp -maxdepth 2 -name '*.php' -ls

Any unexpected .php file in /tmp or /var/tmp means you stop reading buying guides and start treating the host as compromised. That is Patchstack’s own bar and it is the right one.

If you’re on shared hosting and can’t reach raw logs, this is the moment to find out whether your host retains them and will hand them over. Ask specifically for raw access logs covering September 22–26. If the answer is “we don’t provide those,” write that down — it’s a real limitation of your setup and it will matter again.

”But WordPress auto-updates.” Here are the eight ways it didn’t.

Previdian’s CEO gave the accurate summary to The Hacker News: “Because WordPress has auto-updates enabled by default, we’re likely to see mass-exploitation attempts, but relatively few actual compromises.”

That’s true at population scale and it is the reason this isn’t a catastrophe. But “relatively few” is a statistic about everyone else. You care about one site.

WordPress’s default behavior is that WP_AUTO_UPDATE_CORE is effectively 'minor' when undefined — minor and security releases install themselves in the background, major releases wait for a human. 7.1.2 is a minor release, so by default it should have shipped itself to you within hours.

Here is what turns that off, roughly in order of how often I’ve actually found each one on a small-business site:

Constants in wp-config.php override every setting in the admin UI and every filter. So the admin screen can say “automatic updates are enabled” while a constant three hundred lines earlier is quietly overruling it.

The check, in order:

grep -nE "AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE|DISALLOW_FILE_MODS|DISABLE_WP_CRON" wp-config.php
ls -d .git .svn .hg .bzr 2>/dev/null

Two commands. If either one returns anything, you did not have functioning auto-updates, and your exposure window was however long it took you to read this.

Why a CISA deadline matters to a shop with no federal contracts

You have no obligation to CISA. Nobody is auditing you against Binding Operational Directive 22-01.

What the KEV catalog actually is, for a small business, is a free, vendor-neutral, second-opinion signal that a vulnerability has crossed from theoretical to confirmed being used against real targets. Thousands of CVEs get published monthly. A few hundred a year make KEV. The catalog is the cheapest available filter between “your scanner is yelling” and “people are actively doing this right now.”

The due date is the other useful signal, and this one rewards reading closely. BOD 22-01 sets a default remediation window of two weeks for any KEV entry whose CVE ID is from 2021 or later. That’s the standing rule, published years ago. The directive permits CISA to shorten it only “in the case of grave risk to the Federal Enterprise.”

CVE-2026-87902 went into the catalog on September 25 with a due date of September 28. Three days against a two-week default.

CISA doesn’t annotate individual due dates, so read it structurally: the agency reached for its grave-risk exception over a content management system. It did that because a working chain from unauthenticated request to webshell, a public Nuclei template, and roughly two-fifths of the web were all in the same sentence by September 23.

We made the same argument when a CVSS 10.0 landed on SonicWall’s SMA 1000 remote-access appliances and when 996 cheap managed switches got emptied in a night because 564 of them still had the factory password. The pattern repeats: the KEV addition is usually the moment a “you should probably get to that” becomes a “stop what you’re doing.”

The shared-hosting and WooCommerce wrinkles

Two situations make this materially worse, and both are extremely common in the audience this site is written for.

Shared hosting. Conditions 2 and 3 from the exposure table — register_argc_argv on, pearcmd.php present — are properties of the server, not your site. On shared hosting you don’t control either, you often can’t inspect either, and you can’t change either. You are inheriting someone else’s PHP build decisions. Worse, on a badly isolated shared host, a shell in one account’s /tmp is not automatically confined to that account. If you’re on shared hosting, the only honest read is: assume conditions 2 and 3 were true, and lean on the fact that condition 1 (your theme) was the one you controlled.

WooCommerce. If the site takes orders, the file-include primitive sits in the same process that can read wp-config.php, which holds your database credentials, which is where customer names, addresses, emails, and order history live. Card data shouldn’t be there if you’re using a hosted payment gateway correctly — but everything around the card data is. A compromise on a brochure site is an embarrassment and a cleanup. A compromise on a store is a notification question, and that question has state-law answers.

If you run a store, the rest of the week’s work is the boring version: confirm the patch, grep the logs, check /tmp, rotate database and admin credentials, and verify your backups actually restore. We walked through the full version of that sequence in what to do after an e-commerce store compromise, and it applies here almost unchanged. The Magento zero-day earlier this year produced the same shaped week for Adobe Commerce shops.

The uncomfortable platform question

WordPress is running around 41.2% of all websites as of August 2026 per W3Techs, down from a 43.6% peak in mid-2025. That is the sixth consecutive quarter of decline, and open-source CMS share is drifting toward hosted builders.

Does this bug mean you should leave?

Honestly: no, and I want to be careful not to pretend otherwise because a dramatic conclusion would be more fun to write.

Here’s the actual comparison, stated plainly:

The thing that makes WordPress risky is the same thing that makes it survivable: you have the keys. You could check /tmp today. A Squarespace customer with an equivalent bug would learn about it from a status page, after.

What this bug should change is narrower and more actionable: if nobody in your building can name the last time your site’s core version changed, your site is not being maintained, it’s being hoped at. That’s true whether the number on the screen is 7.1.2 or 5.8. We’ve made this argument from the build side in the five pages every local business website actually needs and from the money side in the real cost of a free website builder — the recurring theme is that the sticker price of a website is never the price of a website.

And one more structural note, straight from the WordPress project: “only the most recent version of WordPress is actively supported.” They backported this fix to 4.7 as a stated courtesy. Courtesy is not a maintenance plan. If you are sitting on 6.4.x because a plugin broke on 6.5, the backport saved you this time and will not necessarily save you next time.

The checklist, in the order that actually reduces risk

Thirty minutes, once, today.

1. Confirm the real version. grep "wp_version = " wp-includes/version.php. Not the dashboard.
2. If not patched, patch. Dashboard → Updates, or your host’s control panel, or wp core update if you have WP-CLI. Take a snapshot first if your host makes that one click.
3. Find out why it didn’t patch itself. The two-command grep from the auto-update section. Fix the cause, not just the symptom — otherwise you’ll be here again on the next one.
4. Grep the logs for the traversal and pearcmd signatures, Sept 22 onward.
5. Check /tmp and /var/tmp for unexpected .php files.
6. Run the exposure triage (page-* directory in the active theme and its parent, register_argc_argv, pearcmd.php) so you know how wide the window actually was.
7. If step 5 turned up an unexpected .php file: treat the host as compromised. Rotate WordPress admin passwords, database credentials, SFTP/SSH keys, and hosting panel logins. Rotate them from a machine you can vouch for, not the one you’ve been browsing on. If step 4 found log hits but step 5 is clean, you were scanned and it didn’t land — note the dates, don’t burn the weekend.
8. Verify a restore, don’t just verify a backup. A backup you’ve never restored is a belief, not a control.
9. Write down what you found — version, cause of missed update, log result. Next time this happens, past-you having taken four notes will save present-you an hour.

Step 7 is the one people cut corners on, and it’s the one that decides whether you get compromised twice.

When this doesn’t apply to you

Some honesty about the limits, because a security piece that tells everyone they’re in danger is just marketing:

• If your site isn’t WordPress, none of this touches you. Shopify, Squarespace, Wix, a static site, a hand-built PHP site — different problems, not this one.
• If your site is on well-managed hosting with real auto-updates, you were almost certainly patched within hours and your exposure window was shorter than your lunch. Do steps 1 and 4 anyway; skip the rest.
• If neither your active theme nor its parent has a page-* top-level directory, the specific RCE chain in the wild didn’t line up on your box even during the window. You still should have patched, but you can stop losing sleep.
• If pearcmd.php doesn’t exist on your server and register_argc_argv is off, the public exploit tooling had nothing to grab. Same conclusion.
• If you’re past step 5 with clean results, you’re done. Close the tab. Set a calendar reminder to check your core version monthly and go run your business.

The thing not to do is the middle path: read this, feel bad, patch nothing, and check nothing. Six commands is the entire cost of knowing.

Sources

9 refs

1. WordPress 7.1.2 Release — WordPress News — the official security release announcement: September 22 date, CVE-2026-87902 / GHSA-7hp8-65ch-5whp, credit to Robert Ressl, the backport-to-4.7 statement, the “only the most recent version is actively supported” language, and the automatic-background-update note.wordpress.org
2. WordPress 7.1.2 Security Release: Unauthenticated LFI to RCE — Patchstack — the technical analysis behind the exposure triage: the get_page_template() mechanism in wp-includes/template.php, the missing validate_file() call and the urldecode() step, the three exploitation preconditions (page-* theme directory, register_argc_argv, readable pearcmd.php), the CWE-98 classification, and the two-part structure of the fix.patchstack.com
3. CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch — Patchstack — the exploitation timeline (11:49 UTC first probe, 15:34 UTC first file write, 10x traffic peak on Sept 23), the three-stage attack pattern, the three probed pearcmd.php paths, the dropped filenames, and the log-indicator list this piece’s grep section is built from.patchstack.com
4. Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure — The Hacker News — the 68 documented attempts by September 23, the source IP list, the GitHub-hosted persistence scripts, and the Previdian quote on auto-updates limiting real compromises.thehackernews.com
5. CISA Adds One Known Exploited Vulnerability to Catalog (September 25, 2026) — the KEV addition, the September 28 federal due date, and CISA’s own description of the remote file inclusion.cisa.gov
6. Binding Operational Directive 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities — CISA — the standing KEV remediation timelines used in the deadline section: six months for CVE IDs assigned prior to 2021 and two weeks for all other vulnerabilities, plus the directive’s own language that these defaults “may be adjusted in the case of grave risk to the Federal Enterprise” — which is the basis for reading a three-day due date as an exception rather than a routine entry.cisa.gov
7. WordPress 7.1.2 fixes critical unauthenticated path traversal vulnerability (CVE-2026-87902) — Help Net Security — the CVSS v4.0 9.2 score, the 4.7.0–7.1.1 affected range, and the count of backported branches (7.1.2 plus 24 older releases down to 4.7.37).helpnetsecurity.com
8. Usage Statistics and Market Share of WordPress — W3Techs — the 41.2% share figure for August 2026 and the decline from the mid-2025 peak, used in the platform-question section.w3techs.com
9. A Deep Dive Into WordPress Automatic Updates — Kinsta — documentation of the auto-update constants used in the eight-causes table: WP_AUTO_UPDATE_CORE defaulting to 'minor', AUTOMATIC_UPDATER_DISABLED as a blanket kill switch, DISALLOW_FILE_MODS, and the rule that wp-config.php constants override UI settings and filters.kinsta.com