WordPress 7.1.2 Is Out. Who at Your School Clicks Update?
Quick answer
On September 22, 2026, WordPress released version 7.1.2, a security release that fixes a vulnerability rated critical by the WordPress security team (CVE-2026-87902). An attacker does not need to log in to attempt it, but whether a given site can actually be exploited depends on its theme and server setup. This week: take a backup, update WordPress core to 7.1.2 (or the patched release for your branch), update your plugins and themes, and test your enrollment and donation pages. Every month after that: have one named person do the same routine.
What happened, in plain language
According to the WordPress 7.1.2 release post, the fix addresses a flaw where "an unauthenticated attacker can, under certain conditions," make WordPress load a file it shouldn't. If certain conditions on both the server and the active theme are met, that can lead to remote code execution, meaning someone could run their own code on your site.
The official security advisory (GHSA-7hp8-65ch-5whp) spells out those conditions. In short, it depends on whether your active theme has a certain kind of folder and how PHP is configured on your hosting account. The advisory names some older default themes and a few popular third-party themes as affected, so plenty of sites will meet the theme condition and plenty won't. You don't need to work out which group you're in. The fix is the same either way: update.
It's worth knowing that on September 25 the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added this CVE to its Known Exploited Vulnerabilities catalog. That's a good reason to get this done this week rather than putting it off to next month.
If your site runs an older major version, WordPress backported the fix to every branch back to 4.7 (for example 7.0.6, 6.9.9, and 6.8.10). The version 7.1.2 documentation page lists them. Versions 4.6 and earlier no longer get security fixes.
Why this is really a "who" question
From my experience: In 14 years running marketing and websites for a community college, I learned that the technical part of an update is rarely the hard part. The hard part is that nobody is sure whose job it is. At small schools, charter schools, and education nonprofits across the Southwest, the website often belongs to whoever built it. That might be a volunteer parent, a staffer who has since moved on, or an outside designer who handed over a login years ago. When a security release lands, everyone assumes someone else has it covered.
So here's what I'd do this week, and what I'd put on the calendar from now on.
What to do this week: four steps
Step 1: Take a backup first
Before you change anything, make a full backup of your files and your database. Many hosts offer one-click backups in their control panel, and backup plugins work too. Confirm the backup finished and is stored somewhere other than the site itself. WordPress has guidance on backups if you're starting from scratch.
Done when: you have a dated backup of both files and database, and you know how to restore it (or who to call).
Step 2: Check your WordPress version and update core
Log in and go to Dashboard > Updates. The page tells you which version you're running. If it's older than 7.1.2 (or your branch's patched release), click Update Now. Sites with automatic background updates turned on may already be updated, but check anyway rather than assuming. See WordPress's Updating WordPress guide for details.
Done when: Dashboard > Updates shows 7.1.2 or later (or the patched release for your branch).
Step 3: Update plugins and themes too
Updating core fixes this one issue in core. It doesn't fix an outdated form plugin, an old page builder, or a theme nobody has touched since it was installed. On the same Updates screen, update your plugins and themes. While you're there, remove any plugin or theme you aren't using. Inactive code still sits on the server. You can also turn on automatic updates for plugins and themes where it makes sense.
Done when: the Updates screen shows no pending plugin or theme updates, and unused plugins and themes are deleted.
From my experience: The sites I've seen get into trouble usually weren't behind on one thing. They were behind on everything: core, a dozen plugins, and a theme from a vendor that no longer existed. Core updates get the headlines. Plugins are where the day-to-day risk tends to pile up.
Step 4: Test the pages that matter
After updating, open your most important pages as a visitor would, ideally in a private browser window. For schools, that usually means:
- Enrollment, application, or inquiry forms. Submit a test entry and confirm it arrives where it should.
- Donation pages. Confirm the page loads and the payment step appears. Use a test mode if your processor has one.
- The home page, calendar, and staff or contact directory.
- Anything families use on deadline, such as registration or lunch account links.
Done when: each key page loads correctly, test form submissions arrive, and nothing looks broken on a phone.
What ongoing care looks like: name one owner
This week's update matters, but the lasting fix is structural. Pick one person who owns WordPress updates, and write their name down somewhere your leadership can see it. Then give them a simple monthly routine:
- Back up the site.
- Update core, plugins, and themes.
- Test enrollment, donation, and contact forms.
- Remove anything unused and note what changed.
- Keep an eye on the WordPress security news between cycles, because security releases don't wait for your calendar.
Done when: one person's name is attached to website updates, a monthly date is on their calendar, and a backup person knows where the logins are.
From my experience: The schools that handled website maintenance well weren't the ones with big IT budgets. They were the ones where someone could answer "Who updates the website?" in one sentence.
What this is not (limits)
- Not a diagnosis of your site. Whether this flaw can be used against a particular site depends on its theme and server configuration. This post can't tell you whether yours was exposed.
- Not a guarantee. Updating to 7.1.2 closes this specific issue. It doesn't make a site fully secure. Plugins, themes, passwords, user accounts, and hosting all play a part.
- Not incident response. If you see signs your site was already compromised, like unfamiliar admin users, strange redirects, or warnings from your host, contact your hosting provider or a security professional instead of just clicking update.
- Not legal or compliance advice. If your school has district IT or state reporting requirements, follow those.