Your developer sends the note that WordPress 7.1.1 is out and should go on this week. Somebody asks the reasonable question, which is whether the site is at risk right now. The honest answer depends on a number nobody at your organization currently knows.
The flaw patched on September 17 cannot be triggered by a visitor, by a member, or by a staff member with an Editor account. It needs an administrator, signed in, to open a link. So the length of your administrator list is the actual measure of your exposure, and most associations have not looked at that list in years.
Where this comes from. The release detail below is from the WordPress 7.1.1 release post. The chain detail is from Patchstack, read directly rather than from the news coverage, because several outlets have run this as a drive-by attack and it is not one. Where we describe a limit on the attack, that limit is in the research.
What Shipped on September 17
WordPress 7.1.1 is a maintenance and security release carrying eleven security fixes, with backports going out for versions 4.7 and later. The one that matters here is described flatly in the release notes: specially crafted URLs can automatically install and preview an inactive theme from WordPress.org. It is credited to Paulos Yibelo and pwn.ai.
That wording undersells it, and the researcher published the full chain the next day, on September 18, under the name Click2Shell. A fix on Thursday and a working proof of concept on Friday is the window that actually gets sites taken, because the people who patch monthly have not moved yet and the people reading the disclosure have.
How the Chain Works, in Plain Terms
The root cause is a sanitizing mismatch between two halves of the same feature, which is a category of bug that keeps recurring because it needs two teams to agree and they usually do not.
- One value, two interpretations. A theme slug arrives in a URL. The WordPress.org Themes API cleans it on the server and strips the extra characters. The admin screen JavaScript then drops the original raw slug into a jQuery selector without escaping it.
- The selector is the weak point. Because the selector can be broken out of, a crafted slug makes the install screen behave as though the administrator clicked Install on a theme other than the one shown.
- The second stage does the damage. A theme is now on the site that the administrator did not choose. The proof of concept used Mobile Repair Zone 2.5.4, picked because it ships an AJAX handler that accepts a plugin download URL with no nonce check and no capability check at all.
- Arbitrary code follows. That handler will fetch and install a plugin from a URL the attacker controls, and a plugin is PHP. That is the end of the chain and the reason for the name.
The 7.1.1 fix escapes the theme slug before it reaches the jQuery selector and restricts the selector to actual theme cards, which closes the first step and therefore the whole chain.
The Limits, Stated Plainly
This matters because the coverage has been inconsistent, and an association that reads one version of it will either panic or ignore it, and both are wrong.
- It is not a drive-by. It needs a logged-in administrator to load the attacker's URL. Delivery is targeted phishing, or an existing cross-site scripting foothold that makes the browser send the request.
- Only Administrator can do it. Author and Editor accounts cannot trigger it, because they do not hold the capability to install themes. This is the only good news in the advisory and it is the whole basis of the response.
- The attacker needs nothing. No WordPress account, no installation nonce, no privileges of their own. They only need one of yours to click.
- No CVE and no confirmed exploitation. Patchstack assigns no CVE in its writeup and reports no exploitation in the wild, and we have not found public reporting that establishes any. We would rather say that than imply otherwise.
What survives the qualifiers. What is left after all those qualifiers is still a chain against WordPress core that ends in code execution, with complete technical detail and working proof of concept in public, five days after the patch. It is worth this week rather than next month.
Why This One Lands Differently at an Association
Every organization running WordPress has the same patch to apply. The reason this one is worse for membership organizations is the second half of the precondition, which is the administrator account, and how those tend to accumulate here.
How the list grows. The administrator role gets handed out during a website project, when everyone needs to do everything and nobody wants to be the person blocking the launch. Then the project ends and the list stays. A typical association administrator list, when we finally read one, contains the agency that built the site four years ago, a communications director who left in 2024, an events contractor, one or two board members who asked for access once, and a staff member who needed to publish a page in 2022 and was given the keys because it was faster than explaining roles.
Why nobody notices. Nothing breaks when the list is too long. No page errors, no alert, no line in a report. The site works identically whether you have three administrators or nineteen, which is exactly why nobody has ever been asked to trim it. It only becomes a number that matters on a week like this one, when the question is how many inboxes an attacker has to reach to own the site.
And the delivery is easy. There is a second reason it lands here. Association staff are heavily phished already, because membership organizations publish their staff directory, their leadership, their committee rosters and their conference speakers. An attacker does not have to guess who your administrators might be. In many cases you have listed them, with titles, on a public page.
What to Do This Week
The update is the urgent half. The rest is the half that still matters after this particular flaw is forgotten:
- Apply the patch now. Take 7.1.1, or the backport for whichever branch you are on, and do not hold it for the monthly window. A published proof of concept changes the arithmetic on waiting.
- Then count your administrators. Users, then All Users, then filter by Administrator. Read every name out loud. Most organizations are surprised, and the surprise is usually a former employee or a vendor relationship that ended.
- Demote everyone who does not install software. Editor covers essentially all day-to-day content work: writing, editing, publishing, media, categories. Almost nobody who makes web pages at an association needs the ability to install software.
- Consider turning off dashboard installs. If your site is deployed from a repository rather than updated from the dashboard, DISALLOW_FILE_MODS in wp-config breaks this chain at the first step and several future ones with it. If you install plugins from the dashboard, this is not for you, and that is a separate conversation worth having.
- Two-factor on every remaining administrator. It does not stop the click, but it raises the cost of every credential that leaks from the phishing attempt that delivers the click.
The Part That Outlasts the Patch
7.1.1 closes this chain permanently. It does nothing about the next flaw that requires an administrator, and there will be one, because administrator-required is the most common shape a serious WordPress vulnerability takes.
The denominator is the thing you control. A flaw that needs one of four administrators to be phished is a different risk from one that needs one of nineteen, and the difference is an afternoon of work that costs nothing and recurs annually. Treat the user list the way you treat the plugin list, as something with an owner and a review date rather than something that only gets looked at after an incident.
One note on the rest of the release. Two of the eleven fixes in this release, a path traversal in the REST Templates Controller and a post overwrite available to Contributor accounts, are credited to Anthropic. Make of that what you will, but the practical reading is that more parties are now looking at WordPress core than were looking a year ago, and the rate of advisories like this one is more likely to rise than fall.
We Will Apply It, and Tell You the Number
If nobody at your organization owns the update, that is the finding, and it is a more useful one than the vulnerability. For associations we work with, this release went on within a day of publication and the administrator review happened alongside it, because the two belong together and neither is a project.
If you want it handled this week, we will take the update across your environments and send back the administrator list as it stood when we started, with the ones we would remove, the ones we would demote to Editor, and the ones we cannot judge without asking you. We would rather do this as the standing maintenance it is than as an emergency, which is why patching and access review sit inside our partnership plans rather than arriving as an invoice after a bad week. If you already applied 7.1.1 on Thursday and know your administrator count without looking it up, you do not need us for this one.