Click2Shell and the 17 September WordPress security release (CVE-2026-93485)

WordPress shipped eleven security fixes on 17 September 2026. Two of them carry the news: a link that makes an administrator install a theme they never chose, and a stored cross-site scripting flaw in the function that formats nearly every piece of content WordPress renders.

The first is the one with a name. Researchers at pwn.ai chain the forced theme install and preview into code execution on the server and call it Click2Shell. The second is CVE-2026-93485, an unauthenticated stored cross-site scripting flaw in wpautop(), reached through a comment.

The instruction is the boring one: update WordPress. The part worth reading carefully is what the version number does, and does not, tell you afterwards.

The patched version for your branch

Every branch that still receives security fixes got a backport, currently as far back as 4.7. Compare your site against the patched release for its own branch. A site on 6.8.9 is current. A site on 7.0.4 is not, even though the number is higher.

Branch	First patched release
7.1	7.1.1
7.0	7.0.5
6.9	6.9.8
6.8	6.8.9
6.7	6.7.8
6.6	6.6.8
6.5	6.5.11
6.4	6.4.11
6.3	6.3.11
6.2	6.2.12
6.1	6.1.13
6.0	6.0.15
5.9	5.9.17
5.8	5.8.16
5.7	5.7.18
5.6	5.6.20
5.5	5.5.21
5.4	5.4.22
5.3	5.3.24
5.2	5.2.27
5.1	5.1.25
5.0	5.0.28
4.9	4.9.32
4.8	4.8.31
4.7	4.7.36

WordPress 4.6 and earlier receive no security updates. There is no patched release for those branches and moving to a supported one is the only fix.

One thing to watch if you patched in August: those releases do not cover this one. The 6 August fixes landed on 7.0.3, 6.9.6 and 6.8.7, the 12 August Imagick fixes on 7.0.4, 6.9.7 and 6.8.8. Each September patch sits one release above.

What the chain actually needs

The reported attack starts with a link. An administrator who is logged in opens it, and their own browser is made to install and preview a theme the attacker picked. That much is the WordPress bug, and it is what 7.1.1 fixes.

Code execution is the next step, and it is not WordPress's code that runs it. The chain needs the installed theme to have a handler of its own that executes attacker input. So three things have to be true at the same time:

• an administrator is logged in and opens the crafted link,
• the site still allows theme installs, which most do,
• the theme the attacker chose carries a flaw of its own.

None of that makes it theoretical. It makes it conditional, and the conditions are worth knowing because they are also the things you can check.

Why the ratings disagree

You will see 9.6 in the headlines. That is the researchers' rating for the complete chain, end to end. WordPress rates its own fix for the forced install as medium. Wordfence scores that record 4.3. The unauthenticated stored XSS in the same release scores 7.2.

All three can be right at once, because they are measuring different things: the whole chain, the one bug WordPress fixed, and the separate XSS. When a vendor and a researcher disagree by five points, the useful move is to read what each number covers rather than pick the loudest.

Respira lists this advisory as high. Not 9.6, because the conditions are real, and not medium, because the outcome at the end of the chain is somebody else's code on your server.

The other half of the release

CVE-2026-93485 is the one more sites are exposed to in practice. wpautop() formats almost everything WordPress renders, and the flaw is stored: the payload lives in content and fires for whoever loads the page.

What stands between a visitor and that payload is comment approval. A site that holds comments for moderation has a gate. A site that auto-approves comments, or approves them in bulk without reading them, does not. If that is you, it is worth a look at your discussion settings today.

What to check after updating

Updating closes the door and undoes nothing that happened before it. The version on the site cannot prove the site was never exposed, so here is what can be checked:

• Themes. A forced install leaves the theme behind. Look for themes installed on or after 17 September that nobody remembers installing, and inactive themes you cannot account for. This is the one trace the chain is not able to avoid leaving.
• Administrators. Accounts created or promoted since that date. Confirm each one with whoever runs the site, and never decide from a name or a registration date that an account is fine, or that it is not.
• Application Passwords. An update does not revoke one. Revoke anything unrecognised or no longer needed.
• Unexpected PHP files in theme, plugin, mu-plugin and uploads directories.

If something turns up, restoring from a backup taken before the exposure window beats cleaning by hand. And do not run broad SQL deletes out of a cleanup guide: WordPress content and metadata look similar to the artefacts people tell you to delete.

Checking more than one site

One site is a two-minute job. Twenty client sites is the part that does not get done, which is why the version spread across a fleet is usually worse than anyone expects.

Respira's WordPress vulnerability scanner compares each connected site against this advisory and against the whole Wordfence Intelligence database, refreshed every six hours, and says which branch patch each site needs. A site that already carries the fix is reported as patched with the review still open, rather than as clean, because the two are different claims and only one of them is provable from a version number.

From there the fix is approval-gated: the agent proposes the exact branch update, you approve it, and a second scan produces the receipt. Nothing updates because an AI thought it should.

Sources

• WordPress 7.1.1 maintenance and security release
• Version 7.1.1, with the full backport list
• Wordfence Intelligence vulnerability database

Checked on 22 September 2026. If a version in the table stops matching the official release notes, the release notes are right and this page is stale.