WordPress fixed Comment2Shell in 25 releases on one day; check yours is one of them, and that no plugin arrived first

Nine days, 25 releases

WordPress core shipped 25 security releases on 17 September 2026, one for every branch from 4.7 to 7.1. The flaw they share was reported on 8 September, so the fix took nine days. It is now tracked as CVE-2026-93485 and has been given the name Comment2Shell by the researcher who found it, Rafie Muhammad of Awesome Motive.

In one sentence: a crafted comment could run script in a signed-in administrator's browser, and use that session to add a plugin to the site. The release notes describe it as stored cross-site scripting in wpautop() that an unauthenticated visitor can inject, subject to comment approval.

What this does not establish: that anyone has used it. CISA's enrichment on the CVE record says exploitation "none" and "not automatable", and it is not in CISA's Known Exploited Vulnerabilities catalogue (version 2026.09.21, 1,717 entries). The published score, CVSS 3.1 7.1, rates the script injection alone, not the route to a plugin.

What the record says, and what it leaves out

Stated and not stated, from the release notes, the CVE record and the researcher's write-up

Question	Stated	Not stated
Is it core or a plugin?	WordPress core, all 25 release notes list it
Which versions are fixed?	4.7.36, 4.8.31, 4.9.32, 5.0.28, 5.1.25, 5.2.27, 5.3.24, 5.4.22, 5.5.21, 5.6.20, 5.7.18, 5.8.16, 5.9.17, 6.0.15, 6.1.13, 6.2.12, 6.3.11, 6.4.11, 6.5.11, 6.6.8, 6.7.8, 6.8.9, 6.9.8, 7.0.5 and 7.1.1
Is it exploited?	CISA-ADP: exploitation none; not in KEV	Whether anyone tried it before 17 September
Which themes?	Block themes, including every default theme from Twenty Twenty-Two to Twenty Twenty-Five, and some classic-theme paths	A full list of affected classic themes
Older branches	Fixed back to 4.7	Whether the older branches can be exploited in practice: the researcher tested 7.1
Web application firewalls		Whether a WAF blocks it: this rests on The Hacker News alone

Two small inconsistencies are worth knowing about if you are writing your own advisory. The researcher says he reported to WordPress through HackerOne on 8 September and asked Patchstack for a CVE on 15 September; the CVE credits the Patchstack bug bounty programme, and Patchstack's timeline gives the release as both 17 and 18 September. The CVE text also calls the bug DOM-based XSS, where WordPress and the researcher call it stored XSS. None of this changes what you should do.

What has to be true, and which setting actually stops it

The setting most hardening guides reach for is DISALLOW_FILE_EDIT. It is a good setting, but it only removes the plugin and theme file editors. It does not stop an administrator session from uploading a plugin. The constant that does is DISALLOW_FILE_MODS, and WordPress's own documentation is clear that it also blocks plugin and theme installs and updates and switches off automatic background updates. A site that sets it needs its own, tested update process, or it will fall behind on exactly the kind of fix described here.

Comment approval is not a security control either. WordPress holds a first-time commenter for approval by default, but moderation of other comments is off by default, and the researcher says the first-time hold can be bypassed.

For UK organisations

Automatic minor core updates have been on by default since WordPress 3.7, so most self-hosted sites and nearly all managed hosts will already be on a fixed release. The sites most likely to have missed it are the ones someone deliberately froze: marketing microsites built by an agency, sites under version control where the updater is off, and sites with AUTOMATIC_UPDATER_DISABLED or WP_AUTO_UPDATE_CORE set to false. Those are also the sites nobody is watching.

Updating closes the hole. It does not undo anything done through it before the update. That is the step most advisories skip.

What to do this week

The question to ask

The fix was fast and reached every branch. The question for anyone responsible for a WordPress estate is simpler and harder: for each site, can you show that the update ran, and that nothing was added in the nine days before it did?

Key facts