On September 23 we published a post about the Click2Shell chain, told you to take WordPress 7.1.1 rather than wait for the monthly window, and explained why the number of administrators on your site was the real measure of your exposure. All of that still holds.
WordPress 7.1.2 shipped on September 22, the day before that post went out. We missed it. The security fix in 7.1.2 is more serious than the one we wrote about, and the difference is the part worth your time.
Where this comes from. The release detail is from the WordPress 7.1.2 release post and the version history on WordPress.org, read directly. We have been specific about what is conditional here, because this one is.
Nobody Has to Click Anything
The 7.1.1 flaw we covered needed a logged-in administrator to open a crafted link. That precondition is what made the post about your user list rather than about the patch, and it is why Author and Editor accounts could not trigger it.
The 7.1.2 flaw does not. The 7.1.2 fix removes that condition. The release describes an unauthenticated attacker being able, under certain conditions, to make page template resolution include a chosen readable local PHP file outside the active theme directories, and states that where the preconditions for both the server environment and the active theme are met, this can lead to remote code execution. It was reported by Robert Ressl.
Read the first word. Unauthenticated means no account, no phishing email, and no administrator having a bad morning. The attacker still needs the right server environment and the right theme, which is a real limit we come back to below, but they do not need a person.
Being Precise About the Conditions
This matters because an association running an ordinary theme on standard hosting may not be exposed at all, and we are not going to imply otherwise to make the post land harder.
- The release says under certain conditions. Not every site. The release names preconditions for both the server environment and the active theme. Two independent conditions, and either one failing breaks the chain.
- A file has to be there to include. Local file inclusion needs a readable PHP file on the server worth including. What is reachable depends on how your host lays out the filesystem and what else is sitting on it.
- And the theme has to cooperate. A theme resolving page templates the ordinary way is a different risk from one doing something clever with template paths. Custom association themes built years ago by somebody no longer available are frequently the clever kind.
So why act. We cannot tell you from here whether your site meets those conditions, and neither can anyone selling you a scan on the strength of this advisory. What we can tell you is that the fix is free, it ships in a maintenance release, and working out whether you are exposed costs more than applying it.
Five Days, Two Security Releases
Look at the calendar rather than at either flaw. September 17 brought 7.1.1 with eleven security fixes, with backports to 7.0.5 and the 6.9 extended support line. September 22 brought 7.1.2, with 7.0.6 and 6.9.9 alongside it. Two security releases in five days, both backported across supported branches.
What that cadence means. That is the operating condition now, and it is the thing to plan around rather than either individual CVE. An association on a monthly patch window was already behind on the first release when the second one landed, and would not have learned about either until the window came round.
The honest conclusion. We were watching this subject closely enough to write about it and still published a post naming the superseded version. If it caught us, a communications team with eleven other priorities is not going to catch it by reading more release notes. The answer is that somebody owns applying these within a day, with the access to actually do it, or it is contracted out, or it does not happen.
Why Two Branches Is Not Two Problems
Associations frequently run more than one WordPress site: the main site, a conference microsite, an advocacy campaign site, a chapter site somebody built in 2022. Those are often on different branches, and a release day like September 22 patches all of them at once with different version numbers.
- The main site, probably on 7.1.x. The one everybody checks, because it is the one with the member portal and the one the board asks about.
- The conference microsite, probably on whatever shipped the year it launched. Built for one event, launched, and never touched again. It still runs PHP, still accepts traffic, and still sits on your domain. It is the most likely place for a site to be two branches behind.
- The chapter or affiliate site. Frequently outside the main hosting account, sometimes paid for on somebody personal card, and routinely missing from any inventory.
The point. WordPress backports security fixes a long way down, which is genuinely good of the project and which also means being on an old branch is survivable if somebody is applying the backports. Nobody applying them is the actual problem, and an unmaintained microsite on your domain is a route into the same hosting account as everything else.
What to Do This Week
Short list, and the first item takes a minute:
- Check which version you are on. Every site you own, not just the main one. Dashboard, then Updates. If it says 7.1.1 you took our advice and you are still one release behind. If it says 7.1 you are two behind. On the older branches, check you are on 7.0.6 or 6.9.9.
- Apply 7.1.2, or the backport for your branch. It is a maintenance release, the routine kind, and it closes an unauthenticated path to code execution.
- Then check whether automatic minor updates are still enabled. Automatic updates for minor releases are on by default in WordPress, and a surprising number of association sites had them switched off during some past project and never switched back.
- And if you were behind for a stretch, patched is not the same as clean. A patched site that was already compromised is still compromised. That distinction gets skipped constantly and we have written about it separately.
On Getting It Wrong
This post exists because we got one wrong, so it is worth saying what actually failed. The Click2Shell post was researched, written and queued before 7.1.2 existed, then published a day after it shipped. The writing was fine. What was missing was any step that re-checked the version number between queueing and publishing, on a subject where the version number is the entire recommendation.
What changed here. We have added that check for ourselves: anything version-pegged gets the number verified the morning it runs. We are telling you because the same gap sits in most association communications calendars, where a post about a deadline or a release is approved three weeks out and nobody looks again before it goes. If you publish anything time-pegged, that is a cheap thing to add and it will catch something eventually.
Ask Us What Version You Are Actually Running
A surprising number of associations cannot answer that for every environment they own, because the answer lives in a dashboard somebody else logs into. If that is you, send the URLs and you will get back the core version on each site, which ones are behind the current release, whether automatic minor updates are switched on, and the themes or plugins that would block an update if you tried it today. That needs no access from you and it is the piece of information every other security conversation depends on.