+61 2 9043 1246

Knowledge base

The WordPress pending-comment XSS flaw: the WordPress Core comment moderation bug fixed in 7.1.3, explained for website owners

Published · By , Co-Founder, BLACKBX

WordPress 7.1, 7.1.1 and 7.1.2 contain a stored cross-site scripting flaw on the Comments screen: a stranger’s pending comment can run code when a moderator clicks it. No attacks have been reported. WordPress fixed it in 7.1.3 on 6 October 2026. Check your version and update.

Key fact Advisory
What Stored cross-site scripting (XSS) on the WordPress Comments administration page, triggered through pending comments. No CVE; CWE not published.
Affected WordPress 7.1 through 7.1.2. Not affected: 7.1.3, and versions 4.7 to 7.0.x (which have other 7.1.3 fixes to apply).
Fixed in WordPress 7.1.3, released 6 October 2026. Whether anything newer has been released since is not known.
Severity No score from WordPress. CVSS 7.2 (High) from Wordfence, as carried by our scanner’s feed; not independently verified.
Needs a login? No. Any visitor can leave the comment, but a logged-in moderator has to click for it to run.
Exploited? Not known. No reports of attacks and no public proof of concept found as of 13 October 2026.
Do now Check your WordPress version under Dashboard → Updates and update to 7.1.3 if it shows 7.1, 7.1.1 or 7.1.2.

Facts checked on 13 October 2026 against WordPress.org’s release post and documentation, Patchstack, Pantheon, Jump.bg, MagicWP, Wordify and other coverage of the 7.1.3 release. Sources are listed at the end.

What is the WordPress pending-comment XSS flaw?

WordPress is the software that runs many small-business websites. This flaw is in WordPress itself, often called WordPress Core, not in a plugin or a theme. That matters: there is nothing to switch off or uninstall. The only fix is to update WordPress.

The flaw sits on the Comments administration page. That is the screen inside the WordPress dashboard where your staff read comments that visitors have left, then approve or reject them. Comments waiting for a decision are called “pending” comments.

It is a stored cross-site scripting flaw, usually shortened to stored XSS. Cross-site scripting means an outsider gets their own code to run inside someone else’s web browser while that person is using your site. “Stored” means the code is saved on your website and waits there for someone to open it.

In plain terms, a stranger can leave a comment carrying hidden code. Nobody has to approve it. It sits in your moderation queue, and when someone on your team who can see the Comments page clicks a link the comment has planted there, the code runs in their browser while they are logged in to your dashboard. Wordfence’s description, which our scanner carries but which we could not check against Wordfence’s own page, places the cause in how the dashboard handles links in its help tabs.

The flaw has no CVE number. A CVE is the public reference number most security flaws are given. WordPress did not publish CVE numbers or severity scores for any of the seven security fixes in 7.1.3, so this one is known by its description: the stored XSS on the Comments administration page, exploitable through pending comments, fixed in WordPress 7.1.3.

It was reported by Thomas Chauchefoin at Trail of Bits. One Japanese summary of WordPress’s announcement says the report was made in collaboration with OpenAI; the English copies of the announcement we could read do not mention OpenAI. The date it was reported to WordPress has not been published. The fix shipped in WordPress 7.1.3 on 6 October 2026.

One thing to keep separate. WordPress fixed a different comment-related XSS in 7.1.1, tracked as CVE-2026-93485. That is another flaw in different code, with a different reporter and a different fix. Some coverage blurs the two. This post is about the one fixed in 7.1.3.

Who is affected?

Your site is in scope if all of these are true:

  1. It runs WordPress.
  2. Its WordPress version is 7.1, 7.1.1 or 7.1.2.
  3. Someone who can see the Comments page in the dashboard, usually an administrator or a moderator, opens it and clicks the planted link.

What is not affected:

  • WordPress 7.1.3. That is the fixed release.
  • WordPress 6.5 to 7.0.x. These versions are affected by six of the seven issues fixed in 7.1.3, but not by this pending-comments one.
  • WordPress 4.7 to 6.4.x. Also not affected by this one.

Those “not affected” points come from a hosting company’s write-up and from Patchstack’s review as reported by a third party. We could not open WordPress’s or Wordfence’s own list of affected versions. Every source we found agrees on the affected range of 7.1 to 7.1.2.

If your site is on an older branch, you are clear of this flaw but not of the release. The other six fixes still apply to you, and sources disagree on how far back WordPress had shipped patches for older branches on release day. WordPress’s own announcement, as reported by others, says only the latest version is actively supported.

How many sites run 7.1 to 7.1.2 has not been published.

If your site uses WordPress and has been kept reasonably up to date since 7.1 came out, assume you are in scope until someone checks the version.

What can an attacker do?

Run their code inside the dashboard, in the browser of the person who moderates your comments, while that person is logged in. Whatever that person is allowed to do on your site, code running in their browser can try to do. If they are an administrator, that is everything.

That is not a theoretical stretch. In a separate campaign this month, which used plugin flaws and not this one, Patchstack described attackers using stored XSS to plant an administrator account that hides itself. Patchstack also noted that any stored XSS that shows code to an administrator could deliver the same payload. This flaw is that kind of XSS.

What makes it worse:

  • No login is needed to start it. Any visitor who can leave a comment can plant the code. Patchstack and The Repository both describe it as unauthenticated.
  • The comment never has to be approved. According to Wordfence’s text in our scanner, and the way RS Web Solutions describes the trigger, the comment only needs to be sitting in the moderation queue.
  • It lands in front of the most powerful people on the site. The Comments page is opened by administrators and moderators, the accounts with the most control.

What limits it: someone has to click. Patchstack is clear that a moderator must interact for the code to run. That is a real barrier, but checking pending comments is a routine job, and routine jobs get done on autopilot.

On severity, WordPress gave no score. Wordfence scores it CVSS 7.2, which is High. CVSS is the common 0 to 10 scale used to rate how serious a flaw is. That figure reaches us through our scanner’s feed; we could not open the Wordfence advisory to confirm the score or how it was worked out. There is no score from NVD, the United States government’s vulnerability database, because there is no CVE for it to score.

You may see other numbers in the press. SecurityOnline gives CVSS 7.2 for CVE-2026-93485, the earlier 7.1.1 flaw, and Patchstack and others score that one 7.1. Neither number belongs to the flaw in this post.

Is it being exploited?

No attacks have been reported. WordPress’s announcement does not mention any. SecurityOnline, as reported by Witscode, says there is no confirmed exploitation and no public proof of concept, meaning no published working example of the attack. Cybersecurity News reports that WordPress’s documentation gives no confirmed exploitation details. We found no source that says otherwise as of 13 October 2026.

There is an active XSS campaign against WordPress sites, which is why this is worth taking seriously. Patchstack first saw it on 4 October 2026. It uses flaws in two plugins, WPC Product Bundles for WooCommerce (CVE-2026-93836) and Ninja Forms (CVE-2026-94504), not this WordPress Core flaw. No source we found links this flaw to that campaign. The point is only that people are already running working attacks that turn stored XSS into control of a WordPress site.

CISA, the United States cybersecurity agency, keeps a Known Exploited Vulnerabilities catalogue, a list of flaws it has confirmed are being used in real attacks. A flaw without a CVE cannot be listed there. Our scanner reports it is not on the list; we did not check the catalogue directly.

Some hosts are already shielding customers. Pantheon says it has deployed platform-wide protection against outside abuse of this XSS, and it still tells customers to update.

For an Australian site, the practical reading is this. Nobody has reported attacks, the fix is a week old, and a working method for turning XSS into a hidden administrator account is already in use through other doors. Where your business is located does not change any of that.

What should you do now?

In this order:

  1. Find out your WordPress version. Log in to the dashboard and go to Dashboard → Updates. If it shows 7.1, 7.1.1 or 7.1.2, you are in scope. If you cannot log in, or do not know who can, ask whoever manages the site.
  2. Update to WordPress 7.1.3. On the same screen, click “Update Now”, or download 7.1.3 from WordPress.org. Sites that support automatic background updates will start updating on their own, but check the version rather than assume it happened. Sites that cannot write their own files need a manual update, usually by a developer.
  3. Until the update is done, leave pending comments alone. Ask anyone who moderates comments not to open the Comments page or click links in pending comments until the site shows 7.1.3.
  4. Check whether anything has already happened. WordPress publishes only a one-line description of this flaw, and no signs of compromise have been published. If anyone on your team clicked a link in a pending comment while the site was on 7.1 to 7.1.2, or if anything in the dashboard looks unfamiliar, have a developer review the site. Patchstack’s write-up of the separate plugin campaign describes an attacker account built to hide itself, which is why this is a job for someone who knows where to look, not a quick glance at the Users screen.
  5. If you find signs of compromise, get help before carrying on. Neither WordPress nor the researchers have published clean-up steps for this flaw. Updating alone does not remove anything that was added before the update. A developer needs to work out what changed and put it right.
  6. Record what you did. Write down the version you found, the version you updated to, the date, and who did it. If anything comes up later, that record is the first thing anyone will ask for.
  7. Reduce your exposure. Limit who can moderate comments to the people who need to. Ask your host whether it shields sites from known flaws, as Pantheon has for this one. If your site is on an older branch, it is not affected by this flaw but still needs the other 7.1.3 fixes.

If step one is already beyond what you can find out about your own website, that is the problem this blog exists to talk about. Skip to the bottom.

Why updating is not the whole fix

The update closes the door. It does not tell you whether anyone walked through it.

This flaw has been present since WordPress 7.1. Two later updates, 7.1.1 on 17 September 2026 and 7.1.2 on 22 September 2026, did not fix it. A site that did everything right and installed both was still exposed. The fix arrived on 6 October 2026, a week before this post. Any site still on 7.1.2 today is still open.

If someone on your team clicked a planted link before the update, whatever the code did in that moment stays done. An account created, a setting changed, a file added: the update does not reverse any of it. WordPress has also not published guidance on whether comments planted before the update need to be cleared out of the queue.

So the question is not only “is it updated?” but “who would have noticed?” And on most small-business sites, the honest answer is that nobody is in a position to notice. The host looks after the server: the machine, the network, the backups. The agency that built the site has moved on to other clients. The WordPress and plugin updates belong to no one. They sit in a notification on a dashboard that the owner rarely opens, waiting for someone to decide they are their job.

That is the pattern with most serious WordPress vulnerabilities. The fix arrives quietly, and the gap between the fix and the update is filled by whoever is actually watching the site.

What this looks like with BLACKBX

BLACKBX scans every site it looks after daily against published security advisories. When a client’s site matches a critical advisory, our developers patch it immediately. Lower-severity items are done at the next service. Either way, every update is dated and recorded in the client’s logbook, so there is always an answer to “what version were we on, and when did that change?”

On the Monitor plan, the finding goes to the client’s own developer with the version numbers and our advice, so the people who know the site can act on it. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Date Event
Date not published Thomas Chauchefoin of Trail of Bits reports the flaw to WordPress.
17 September 2026 WordPress 7.1.1 released. It fixes a different comment XSS (CVE-2026-93485), not this flaw.
22 September 2026 WordPress 7.1.2 released. It does not fix this flaw.
4 October 2026 Patchstack first sees a separate XSS campaign using plugin flaws, not this Core flaw.
6 October 2026 WordPress 7.1.3 released with the fix, alongside six other security fixes.
6 October 2026 Patchstack adds the 7.1.3 vulnerabilities to its database. Pantheon deploys platform-wide protection. Wordfence advisory published, according to our scanner.
7 October 2026 Press coverage begins, including Cybersecurity News.
8 October 2026 Further coverage, including Private DevOps.
13 October 2026 This article published.

Sources

Common questions

What is the WordPress pending-comment XSS flaw?

The WordPress pending-comment XSS flaw is a stored cross-site scripting bug on the Comments screen of the WordPress dashboard, in versions 7.1 to 7.1.2. A visitor can leave a comment carrying hidden code that runs when a logged-in moderator clicks a link it plants, even before the comment is approved. WordPress fixed it in 7.1.3 on 6 October 2026. BLACKBX checks every site it looks after against advisories like this one daily.

Is my WordPress site affected by the pending-comment XSS flaw?

Your site is affected by the WordPress pending-comment XSS flaw if it runs WordPress 7.1, 7.1.1 or 7.1.2. Versions 7.1.3 and later are fixed, and versions 4.7 to 7.0.x are reported as not affected by this particular flaw. You can see your version under Dashboard → Updates. For sites BLACKBX looks after, this check happens daily and the result is recorded in the client’s logbook.

Does the WordPress pending-comment XSS flaw have a CVE number?

No. WordPress did not publish CVE numbers or severity scores for any of the fixes in 7.1.3, so the WordPress pending-comment XSS flaw is known by its description. Do not confuse it with CVE-2026-93485, a different comment-related XSS fixed in 7.1.1. BLACKBX tracks both through published advisories and records which fix each client site has.

Is the WordPress pending-comment XSS flaw being exploited?

No attacks using the WordPress pending-comment XSS flaw had been reported as of 13 October 2026, and no public proof of concept was found. A separate XSS campaign is using plugin flaws to plant hidden administrator accounts, and Patchstack has said any stored XSS shown to an administrator could deliver the same payload. BLACKBX treats that as a reason to update promptly rather than wait.

How do I fix the WordPress pending-comment XSS flaw?

Update WordPress to 7.1.3 through Dashboard → Updates → “Update Now”, or by downloading it from WordPress.org. Some sites update automatically, but check the version rather than assume. Sites that cannot write their own files need a manual update. On BLACKBX Maintenance and Full service plans, our developers do this work and log it; on the Monitor plan, we send the finding and advice to your own developer.

Do I need to do anything after updating to WordPress 7.1.3?

Updating closes the WordPress pending-comment XSS flaw but does not undo anything done before the update. No signs of compromise or clean-up steps have been published, so if anyone clicked a link in a pending comment while on 7.1 to 7.1.2, have a developer review the site. BLACKBX records every update with its date in the client’s logbook, so the exposure window is always known.

Is this your site?

Do you know which WordPress version your site is running today?

Tell us your website address and we will tell you whether the WordPress pending-comment XSS flaw applies to it. If it does, we can fix it and keep watching the site from here on.

Ask us if this applies to you Get these alerts by email

Or call +61 2 9043 1246. Monthly plans, no minimum term.