CSIPE

Published

- 17 min read

Your WordPress Patch Needs a Look Back

WordPress Website Security Small Business

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

If you run a WordPress site for a shop, club, charity, portfolio, or family business, there is one job worth moving to the front of today’s list. Open the site’s Updates screen and check the version that is actually running. WordPress released version 7.1.2 on 22 September 2026 to repair a critical flaw in the software at the centre of the site, and WordPress recommends updating immediately.

The good news comes first. An update closes the faulty route, automatic background updates may already have installed a repaired version, and there is no reason to assume that every older site was broken into. The flaw needed a particular mix of theme folders and server features before it could reach its worst outcome. The researcher who found it is explicit that his evidence does not show every default WordPress installation was exploitable.

There is still a second job after the update. A repair installed on Thursday tells you what the site will do next; it cannot tell you what happened on Tuesday night. Security companies began seeing hostile checks within hours of the public fix, and by 23 September some requests had moved beyond simple testing into attempts to write files and run code. Your sensible finish line is therefore a small receipt: the repaired version is active, the important files still match trusted copies, the administrator list makes sense, and someone has checked the short period before the door closed.

That sounds more technical than it needs to be. If a host or web developer manages the site, you can ask them for that receipt in ordinary language. If you manage it yourself, this article gives you the safe sequence and tells you where to stop. You do not have to become a server investigator before lunch.

What WordPress repaired on 22 September

WordPress builds a page by choosing a PHP template from the active theme. Think of the template as the form used to present a particular kind of page: a standard page, a landing page, or a contact page. The visitor asks for a page, WordPress works out which template belongs to it, and the server loads that local file to produce the result in the browser.

CVE-2026-87902 let an unauthenticated visitor interfere with that choice. WordPress describes the fault carefully: under certain conditions, a visitor could make page-template resolution include a readable local PHP file outside the active theme directories. If the theme and server also supplied the right ingredients, that local file could become a route to running code on the server. No WordPress account, password, or click from an administrator was required for the demonstrated chain.

A homely analogy helps. Imagine a café keeps approved order forms in one drawer. A customer should be able to name the kind of form they need, while the person behind the counter decides which file in that drawer to use. The flaw allowed a specially written request to make the filing path climb out of the approved drawer and point towards another readable PHP file elsewhere in the cabinet. WordPress still added parts of the expected filename, so the attacker did not get a free choice of every file on every server, but the boundary around the theme directory had failed.

The distinction between reading or including a local file and running any code an attacker chooses matters. The researcher’s working route depended on several extra conditions: a suitable top-level folder in the active theme, a readable PHP target on the server, and server settings that made that target useful. His tests used PEAR components in a particular PHP environment. PEAR is not required by WordPress, and the researcher did not measure how common the complete set of conditions was.

That is why two dramatic sentences can both mislead. “Every old WordPress site could be taken over” goes beyond the evidence. “It was only a theoretical file-reading issue” understates what happened on servers that met the conditions. The accurate middle is firm enough: a visitor without an account could cross a file boundary in WordPress core, and some ordinary server and theme arrangements could turn that mistake into code execution.

The affected range was broad because the faulty logic had been present for years. Independent coverage from Help Net Security reports that WordPress versions 4.7.0 through 7.1.1 were listed as affected. WordPress backported the repair through its older 4.7 branch as a courtesy, although the project reminds site owners that only the newest WordPress version is actively supported. The practical lesson is to use the repaired release offered for your branch now, then make a planned move to a current supported branch if the site has been living on an old one.

Why an automatic update deserves a receipt

Automatic updates are useful precisely because most people have better things to do than watch security bulletins. WordPress says sites that support automatic background updates should begin the update process on their own. That can shrink the open window from days to hours without asking a café owner or volunteer treasurer to notice a CVE number.

“Should begin” is not the same as “finished on this site.” A host can delay a rollout, a site can be unable to write its own files, an update can stall, or a dashboard can be showing an old cached page. Give useful automation a cheap finishing check rather than distrusting it.

Sign in through the address you normally use, rather than through a link in an unexpected email. Open Dashboard, then Updates, and read the current WordPress version shown there. For the newest branch discussed in the 22 September release, you want 7.1.2 or later. An older branch may show its own backported fixed release instead, so do not guess the number if a host maintains that branch for you. Ask the host to name the installed version and link it to the WordPress advisory.

If the dashboard offers the security update, make a backup first and use Update Now. WordPress’s own updating guide recommends backing up before an update and explains the normal one-click route. A managed host may have a separate update panel; use the host’s documented process when it owns the WordPress files. Do not download a “security patch” from an advert, an unsolicited message, or a site that merely resembles WordPress.org.

After the process says it has finished, open the Updates screen again in a fresh tab and record what it says. A screenshot containing the site name, date, and running version is enough for a tiny site. A maintenance company can provide a ticket or report instead. The format matters less than the answer: which repaired version is running on which site, and when was it checked?

Now visit the public home page, one ordinary article or product page, the contact form, and the sign-in page. You are making a quick service check, not conducting a security investigation. Confirm that the update did not leave the site showing a maintenance notice or an obvious error. If something looks wrong, keep the screenshot and contact the host rather than repeatedly reinstalling files until the evidence disappears.

The patch closes tomorrow’s route, not yesterday’s window

The release went public on 22 September. Patchstack says it saw the first matching hostile requests that day and later updated its report as the traffic changed. By 23 September, its sensors were seeing attempts to reach a command-capable PHP file and attempts to write attacker-controlled PHP content to temporary folders. The company’s updated account separates the early probes from the later code-execution attempts rather than treating every request as a successful intrusion.

A second monitoring account gives useful independent support without proving the same sites were affected. The Hacker News reported that Previdian telemetry had recorded 68 exploitation attempts beginning on 23 September. Those are observed attempts, not 68 confirmed takeovers. Sensor counts tell us the public flaw attracted real attention quickly; they do not tell us whether your site met the necessary conditions or whether any request succeeded.

This distinction changes what a calm response looks like. You should update promptly because the route is serious and public. You should look back because attempts appeared during the gap around disclosure and rollout. You should not declare a breach solely because the site ran an older version for a few hours.

Picture a photographer who runs a portfolio site and accepts enquiries through a form. The host installs the fixed WordPress release overnight. The site looks normal in the morning, and no customer has complained. That is encouraging, but appearance alone cannot show whether a new administrator was added, a core file was changed, or a scheduled task was planted before the update.

The photographer does not need to pull the server apart. They need to ask the host four bounded questions: when did this site receive the fixed release, did the site meet the published theme and server conditions, do the logs show requests matching CVE-2026-87902 before that time, and did any important files or accounts change unexpectedly? A good host can answer or explain what evidence it retains. A vague “we are protected” is not the same answer.

The look-back window can also stay narrow. Start with the public disclosure on 22 September 2026 and continue through the verified installation time. If the host knows it deployed a protective firewall rule earlier, ask it to include the rule time and evidence in the reply. If suspicious activity appears, the investigator may widen the window. Beginning with a defined period keeps a sensible check from becoming an endless archaeology project.

What a small-site owner can check safely

A normal WordPress dashboard provides a few useful signals. It cannot certify every server file, and a skilled intruder can hide from a dashboard view, so treat these checks as triage rather than a clean bill of health. Their value lies in noticing a clear mismatch and giving the host a concrete starting point.

Open Users and review every account with the Administrator role. Each one should belong to a person or service you recognise. Pay attention to a familiar-looking name with a new email address, an old developer who no longer works on the site, or a generic account whose owner nobody can name. Do not delete a mystery administrator in a rush if the site is managed; take a screenshot, record the username and email address, and ask the host or developer to identify it first.

Next, check Plugins and Appearance, then compare what you see with the site’s last maintenance record. A newly installed plugin or theme deserves an explanation. So does an old component that is disabled but still present, because inactive code remains on the server. This CVE sits in WordPress core rather than in a plugin, yet the component list helps you spot broader changes and gives an investigator a map of the site.

Look at recent pages and posts for changes you did not make, especially hidden drafts, altered links, or unfamiliar code pasted into reusable blocks. Submit the contact form once using a harmless test address and confirm it reaches the expected mailbox. Open the site from a private browser window and search its name on a search engine to see whether the result title or description has become an advert for something unrelated.

These checks find obvious damage. They do not prove the files underneath are untouched. For that, a host or developer should compare WordPress core files with the official copies for the installed release. WordPress’s command-line tool provides wp core verify-checksums, which checks core files against WordPress.org’s published checksums. A checksum is a file’s fingerprint: when the content changes, the fingerprint changes too.

Ask for the result rather than running an unfamiliar command on a live business site. The useful wording is plain: “Please verify the WordPress core files against the official checksums for the running version and tell me about every mismatch.” Core verification does not cover custom themes, uploaded media, the database, every plugin, or files deliberately placed outside the normal core set. It is one strong comparison, not a universal scanner.

A host should also inspect the web server, PHP, firewall, and WordPress security logs it retains for the look-back window. The public technical reports contain request patterns that a competent operator can search for. There is little value in pasting those patterns into a message to a non-technical owner, and publishing a copy-and-run attack request would make this article less useful, not more. The owner’s job is to set the scope and demand a dated answer.

Backups add another view. Confirm that a backup from before the update exists, that it is stored somewhere the website cannot rewrite, and that the host knows how to restore it without erasing current evidence. Do not restore an old backup over the live site merely because a scanner displayed a warning. A blind restore can remove logs, reintroduce the vulnerable software, and destroy newer orders or enquiries.

The request to send your host or developer

A good support request is specific enough to produce evidence and short enough to be read. You can copy the message below, replace the brackets, and send it through the host’s real support portal. Avoid sending administrator passwords, backup archives, or database files by ordinary email.

Our WordPress site at [site address] may have been running a version affected by CVE-2026-87902. Please confirm the exact fixed WordPress version now active and the UTC time it was installed. Please check whether our active theme and PHP environment met the published conditions, review retained logs from 22 September 2026 through the installation time for matching attempts, verify WordPress core files against official checksums, and review administrator accounts and unexpected PHP file changes. Please tell us what evidence was checked, what the result was, and whether you recommend preserving the site for incident response.

That message asks for five answers without pretending you know the host’s architecture. It also asks for times in UTC, which avoids a muddle when the host, developer, and business are in different time zones. If the provider has already investigated all customer sites, it should be able to point to an incident notice or attach the relevant result.

Read the reply for verbs and objects. “We installed WordPress 7.1.2 at 03:14 UTC and found no matching requests in the retained access log” is useful. “Security is our highest priority and all systems are monitored” tells you nothing about this site. Ask once more for the installed version, the checked time window, and the checks performed.

A small business using a care plan should expect the maintenance company to own this work. If nobody knows who owns it, today’s vulnerability has exposed an organisational problem as well as a software one. Record one named contact for WordPress core updates, one route for urgent security messages, and one place where update receipts live. That small arrangement will outlast this particular flaw.

If the host says it has no access logs from the period, record that limitation instead of accepting invented certainty. Other evidence may still help: file modification times, deployment history, backups, firewall records, administrator audit logs, and external monitoring. The conclusion may be “we found no suspicious change in the evidence available, but the access logs had already expired.” Honest limits are part of a trustworthy receipt.

If you find a mismatch

An unknown administrator, altered core file, unexpected PHP file, strange redirect, or matching exploit request is a reason to preserve and escalate. It is not a reason to click every “clean my site” advert in the search results. Keep the site, logs, and backups as they are long enough for a competent person to understand what changed.

Start by taking screenshots and noting the UTC time. Contact the host through its known portal and say that you may have an active compromise. Ask it to preserve access logs, PHP logs, firewall records, file metadata, and a copy of the site before cleanup. If the site handles payments, health information, member records, or other sensitive data, involve the person responsible for legal and privacy obligations early rather than deciding alone that the incident is too small to matter.

The host may temporarily restrict the site, put it into maintenance mode, or isolate the account from other sites on the same server. That can be inconvenient. It is also better than leaving a suspected foothold connected while people continue changing files around it. Keep a separate list of any business functions affected, such as orders, bookings, donations, or contact forms, so recovery restores the service people actually rely on.

WordPress’s own hacked-site guidance recommends documenting what happened, contacting the host, scanning the local computers used to administer the site, changing access credentials, and replacing compromised files with clean copies. The full WordPress recovery guidance is written for site owners and makes an important point: cleanup extends beyond the visible home page.

Passwords come after evidence preservation and from a clean device. Change the hosting account, WordPress administrators, database access, file-transfer accounts, deployment keys, and any reused secrets that the investigation identifies. Revoke old sessions and remove accounts that no longer need access. If a mailbox controls password resets for the site, protect that mailbox with its own strong, unique password and two-factor authentication.

Recovery should use known-clean WordPress core files, themes, and plugins from trusted sources. Custom code needs review rather than automatic replacement. The database and upload folders require separate inspection because a clean core checksum cannot speak for them. Once the site is rebuilt or cleaned, update again, verify the running version, test its public functions, and watch the logs for renewed attempts.

Do not quietly erase the site and call the absence of an alert proof of safety. A hasty reinstall may make the page look normal while leaving an unfamiliar administrator, scheduled task, database change, stolen credential, or neighbouring account untouched. Appearance is a customer-facing test. Recovery requires a technical account of what was trusted, what was replaced, and what credentials were reset.

The ten-minute finish for a site that looks clean

Most readers will not find an obvious mismatch. For them, the work can end with a short record rather than weeks of worry. Put the site address, running WordPress version, update time, person or provider who checked it, and the look-back result in the place where you keep domain and hosting details.

Then make sure the next security release has an owner. Automatic background updates are a sensible default for WordPress core on a straightforward site, provided someone receives failure notices and checks the result. More complex sites may stage updates first because a failed checkout or booking form has real costs. Either way, the process needs a named human or company and a small proof that the update landed.

Keep the software supported. WordPress provided backports through 4.7 for this flaw, which helps sites close the immediate route, but an emergency courtesy patch does not turn a decade-old branch into a comfortable long-term home. Ask for a dated plan to move to the current release, test the theme and plugins, and retire components that prevent the move.

Keep backups beyond the website’s own reach and test a restore periodically. A backup stored only inside the same hosting account can be changed by the same account that changes the site. One copy held by the host and another under separate control give you a better route back. The test should restore to a safe location, not overwrite the live site during a quiet afternoon.

Finally, shorten the gap between “a release exists” and “this site is confirmed repaired.” For a small site, the receipt can be four lines in a maintenance log. For an agency, it can be a report across every customer site. The scale changes; the question stays wonderfully plain: which version is running here now?

The 22 September WordPress release deserves prompt action, but it does not deserve panic. Install the repair, prove it is active, and ask one bounded question about the hours before it arrived. Then keep the receipt and get back to running the thing the website was built to support.

For calm, practical security guidance without a daily flood of warnings, join the newsletter. It is one email per month.

Sources