WordPress 7.1.2 security update: what to do today

Maybe it was an email from your host, a red notice in your dashboard, or a headline saying a critical WordPress flaw lets attackers in without logging in. Now you are checking your own site, possibly after hours, and wondering two things at once: is it already too late, and will clicking Update break the thing that brings in your customers? The WordPress 7.1.2 security update, released September 22, 2026, closes that hole, and for a normally configured site it is a one-click job that may already have happened on its own. The flaw is real and attackers started probing for it within hours of the fix, but it only reaches the worst outcome on sites with specific server and theme conditions. Updating shuts the door going forward. It cannot tell you whether anyone walked through it first, and that part takes a short, specific check. You can do all of it yourself tonight, in order, and know where your site stands by the time you close the laptop.

Close the hole today with the right WordPress 7.1.2 update

Update WordPress today to 7.1.2, or to the patched security release listed for the branch your site runs. WordPress fixed CVE-2026-87902, an unauthenticated path traversal flaw that can lead to code execution when specific server and theme conditions exist. The WordPress 7.1.2 release announcement, dated September 22, is direct about it: "Because this is a security release, it is recommended that you update your sites immediately." Status below was last checked September 23, 2026.

In practical terms, "path traversal" means a request can trick WordPress into reaching outside the folder it should be reading from. Here, the weak spot is the code that decides which page template to load. According to WordPress and the CVE-2026-87902 record, an attacker who has no login can make WordPress include a readable PHP file that sits outside the active theme's folders. "Unauthenticated" is the part that makes headlines: nobody needs a username or password to try it.

It helps to know which release did what, because two security releases landed within a week of each other and headlines mix them up.

If your site is on 7.1.1, you are not covered. The 7.1.1 maintenance and security release was a separate fix list, covering flaws such as the Click2Shell WordPress vulnerability, and came out before this flaw was patched. The version 7.1.2 documentation lists the fixed release for each supported branch, so if you are on an older line such as 6.x, look up your branch there rather than guessing the number. Versions 4.6 and earlier no longer receive security fixes at all.

Know whether your site is really exposed

The worst outcome in the headlines, a stranger running code on your server, is not automatic. WordPress and the CVE description both say remote code execution depends on relevant server and active-theme preconditions. A site that lacks those conditions is still running a flawed version and still needs the patch, but it is not in the same position as one that has them. You cannot easily tell from the dashboard which group you are in, which is the best reason to patch now rather than try to work it out.

You may also see two different severity numbers. The CVE record, published September 22 by the organization that assigns the identifier, scores it 8.1, High. Patchstack, a WordPress security firm, rates it 9.2, Critical, in its own advisory. Both are real, but only the 8.1 is the official score on the CVE. Either number points to the same action: update today.

Exploitation is where the story moved fastest, so dates matter here.

Read that timeline for what it shows. Attackers are actively scanning and trying to plant files, according to Patchstack. That is evidence of attempts across the internet. It is not a count of hacked sites, and it does not mean your site was compromised. The US government's Known Exploited Vulnerabilities catalog had no entry for this CVE on September 23, and that could change, so check it again if you are reading this later. What the timeline does settle is timing: waiting a few days for more headlines is not a safer choice than updating now.

Find out whether the automatic update already protected you

There is a good chance your site patched itself. WordPress introduced automatic background updates in version 3.7, and existing installs receive minor core updates, like 7.1.2, by default. New installs from 5.6 onward receive both minor and major core updates by default, unless WordPress detects a version-control checkout. The release announcement says sites that support background updates will begin updating automatically.

"Will begin" is not the same as "did", though. The WordPress guide to configuring automatic background updates documents the ways it gets switched off or blocked:

• A disabled updater: A line in the site's configuration setting `AUTOMATIC_UPDATER_DISABLED`, or `WP_AUTO_UPDATE_CORE` set to `false`, stops core updates.
• An update filter: A plugin or custom code can filter updates off without anything showing on the front of the site.
• File permission or FTP limits: If WordPress cannot write its own files without credentials, it cannot update itself in the background.
• Version-control deployments: Sites deployed from a code repository are left alone on purpose, so a developer has to ship the update.
• Host-level management: Some hosts turn off WordPress's own updater and handle updates on their schedule instead.

A host email saying "we manage updates" is good news, but it is not proof that this particular site is on 7.1.2. The only proof is the version number on your own dashboard, which the next section walks through. And if your site runs 4.6 or earlier, no automatic patch is coming. That site needs a planned upgrade to a supported branch, not a wait.

Update safely in four steps without breaking the site

The fear that an update will break the site is reasonable, and the way to handle it is order, not delay. WordPress's own guide to updating WordPress recommends a backup first and says a backup can be restored if a problem follows the update. The four steps below take a normal site from exposed to confirmed in well under an hour. If the site has custom code changes to WordPress core or a dated plugin or theme, the backup step matters even more.

Make a backup you can actually restore

Before touching anything, confirm you have a full backup of both the files and the database, and know three things about it: when it was taken, where it is stored, and how you would restore it. A backup made by your host counts if you know how to trigger a restore. If you have no backup at all, make one now. It cannot rewind to a time before the flaw was public, but it gives you a way back if the update goes wrong.

Run the update from Dashboard > Updates

Sign in at your real `/wp-admin` address, typed yourself rather than from a link in an email, and open Dashboard > Updates. The Updates screen documentation shows where WordPress lists available core updates, and the release announcement tells owners to click Update Now. On a normal site it takes a minute or two.

Confirm the version number changed

When it finishes, go back to Dashboard > Updates and read the version WordPress reports. It should say 7.1.2, or the patched release for your branch listed on WordPress.org. If the update failed, the screen usually shows an error message; write it down, because it tells whoever helps you where to start.

Test what earns you money

Open the public site in a private browser window and check the pages and actions that matter to your business: the home page, a service page, the contact form, a booking or checkout, and the login. Send yourself a test form. If something broke, you have a restore point, and you have a precise description of what failed.

Confirm nobody got in before the patch

Updating closes the vulnerable path, but it does not remove a file or account an attacker may already have created. These checks take a few minutes each and are the difference between knowing your site is clean and hoping it is. If you have handled a plugin warning before, the pattern will feel familiar from our post on what to do about a WordPress plugin vulnerability warning, with the difference that this time the flaw sat in WordPress itself.

Start inside the dashboard, where no technical skill is needed:

• Users: Open Users > All Users, filter to Administrators, and compare every name, email, role and creation date with the people who should have access. Look for editors with unexplained extra rights and for recently changed application passwords.
• Plugins and themes: Look for anything installed or changed that nobody on your side can account for, including must-use plugins, which do not appear in the normal plugin list.
• Scheduled tasks: Unfamiliar scheduled jobs can be a way to keep access after the hole is closed.

Then, if you or your host can get to the access logs, search from September 22 onward for the patterns Patchstack describes: `pagename` with encoded traversal characters, `page_id` together with `pagename`, and the strings `pearcmd`, `+config-show` or `+config-create`. Patchstack also says unexpected PHP files in `/tmp` or `/var/tmp`, including files named `wp-pear-rce-flag.php` or `poc87902.php`, or names beginning with `luci_` or `zeta_`, are signs that an attempt at planting files succeeded.

Finally, look at recently added or changed files. WordPress's hardening guidance advises monitoring changed and added files, and Wordfence's guide to cleaning a hacked WordPress site notes that new files in `wp-admin` and `wp-includes` are very unusual. Your host's file manager can often sort files by date.

A clean result on all of this is reassuring. It is not a guarantee about the past, because logs can be incomplete and some traces are hard to spot, so keep your backups and logs rather than deleting them.

Know exactly when to stop and call for help

If any check turns up something real, such as an administrator nobody recognizes, one of the named files, or log lines matching the patterns above, stop treating this as a routine update. Preserve the logs and take a backup of the site as it is now, before cleaning anything, so there is evidence to work from. Then change passwords, restrict access where you can, and get incident-response help. WordPress's FAQ for hacked sites covers the recovery steps, and our post on the first 24 hours after a website is hacked walks through the order.

What you should not do is just as useful to know. Do not disable updates, turn off security features, edit core files, or install unknown "fix" plugins. A firewall plugin can add a layer, but it is not a substitute for the patched WordPress release. And do not spend the first hour changing permalinks or switching off legitimate plugins in a panic.

The size of the job depends on what you find:

On the other side of that line: if your site is on 7.1.2 or its branch's patched release, you have a recent backup you can restore, the site works, the administrator list is familiar, and none of the named indicators show up, you may not need paid help at all. A careful update and a short test can be the whole job. A warning email by itself is not a reason to buy a cleanup.

Run the ten-minute check before you close the laptop

If you want the whole thing in one pass, this is the order.

If every line comes back clean, you have done what WordPress asked of site owners on September 22. If any line does not, you now know exactly which one, and that is what the person helping you will need first.

Frequently Asked Questions About wordpress 7.1.2 security update

What does the WordPress 7.1.2 security update fix?

It fixes CVE-2026-87902, an unauthenticated path traversal flaw in how WordPress resolves page templates. It can let an attacker include a readable PHP file outside the active theme, and it can lead to remote code execution only when certain server and theme conditions are met.

Do I need to install WordPress 7.1.2 today?

Yes. WordPress's September 22 announcement recommends updating immediately. If your site is on an older supported branch, install the patched release for that branch listed on WordPress.org.

Is CVE-2026-87902 being exploited?

Patchstack reported probes starting September 22 and attempts to write files to disk on September 23. That shows active attempts, not that any particular site was breached. CISA's exploited vulnerabilities catalog did not list it as of September 23.

Will WordPress update to 7.1.2 automatically?

Usually, for sites with background updates turned on. Settings, update filters, file permissions, version-control deployments or host management can stop it, so check the version on Dashboard > Updates yourself.

What if my site runs an older version of WordPress?

The fix was backported to every branch back to 4.7, so install your branch's patched release. Sites on 4.6 or earlier get no security fix and need a planned upgrade.

How do I check whether my site was hacked through this flaw?

Review administrator accounts, recent plugin, theme and file changes, and access logs from September 22 onward for the patterns Patchstack names, and look for the named PHP files in temporary folders. If you find any of them, preserve the evidence and get incident-response help.

What This Means for You

WordPress 7.1.2 closes a real flaw that attackers began probing within hours of the fix, and for a normally configured site the remedy is a single update that may already have run. The worst outcome depends on server and theme conditions, the official score is 8.1 High, and Patchstack's reports show attempts rather than a list of victims. Confirm the version yourself, keep a backup you can restore, and run the short check for users, changes, logs and files.

Once that is done, you are not relying on a headline or a host email to tell you whether your site is safe. You have the version number, a restore point and a clean administrator list, and the next security release becomes a routine five minutes instead of a late-night scramble.

If any step in the check did not come back clean, or you would rather someone else confirm it, Web Leveling can help. Our website security audit looks at the version, the backups, the user list, the logs and the files, and it tells you plainly whether there is anything to clean up or nothing to worry about. We work with small and medium businesses across the country and overseas. Send us what your dashboard and host are showing, and we will tell you what we see and what, if anything, needs doing next.

Terms