A 7.5 record published this morning describes a way to strip an account’s completed email second factor without a session; the code fix has been shipping since September 1 under a changelog line that reads like a display bug.
What happened
NVD published CVE-2026-89080 at 6:16 a.m. UTC on Sunday, September 13, 2026, and revised it again at 11:16 a.m. UTC the same morning. The assigning source is WPScan, whose own advisory for the issue is dated September 11, 2026 and is the record’s only reference. The base score is 7.5 under CVSS v3.1, with the vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, and the weakness is classified CWE-287, improper authentication.
The description is worth reading in full, because the useful detail is in its clauses. The plugin “does not prevent an unauthenticated request from resetting an account’s completed email two-factor enrolment, allowing an attacker who already knows the account’s password to bypass the second factor and obtain that user’s session, up to administrator.” WPScan titles the same finding “Really Simple Security < 9.8.1 – Unauthenticated 2FA Bypass via Email Provider State Demotion,” and credits the researcher Charles Vosburgh.
Affected versions run from 9.5.10.1 up to, but not including, 9.8.1. The record does not say why the range starts where it does rather than at the beginning of the plugin’s history.
The product is Really Simple Security, formerly Really Simple SSL, which WordPress.org lists at more than three million active installations. Version 9.8.1 is current and was published on September 1, 2026 — twelve days before the record describing what it fixed. Its changelog carries three security lines, and one of them is this flaw: “Security: Prevented a bug that incorrectly changed the 2FA status from active to open.” The other two read “Security: Prevented unexpected deletion of the login nonce” and “Security: Prevent XML-RPC logins without 2FA for users with 2FA configured.” This morning’s WPScan batch, which carried nine WordPress plugin records in a single minute, contained one for this plugin.
What “unauthenticated” means here, and what it does not
The word will travel further than the sentence around it, so it is worth pinning down. The record and the WPScan title both say unauthenticated, and the CVSS vector says PR:L — privileges required, low. Those are not in conflict; they describe different steps.
The request that demotes the second-factor state needs no session. That is the unauthenticated part, and it is what makes this reachable by anyone who can send HTTP to the site. But clearing the second factor is not the same as logging in. To convert it into a session, the attacker still has to pass the first factor, which means already holding the account’s password — from reuse, from an unrelated breach, from a phish, or from a prior compromise. That requirement is what the vector encodes.
So this is not a pre-authentication administrator takeover, and anyone reporting it as one is overstating it. What it is, precisely, is the removal of the control whose entire job is to make a stolen password insufficient. The blast radius is every account on the site whose password is already known or knowable, and for those accounts the second factor stops counting. AC:H reflects the conditions; C:H/I:H/A:H reflects what follows once they are met.
Why it matters
The uncomfortable part is what the software is for. This is not an ecommerce plugin that happens to hold sessions — it is the component an administrator installed specifically to add a second factor, and the finding is that the second factor could be taken away by an unauthenticated request. Anyone who deployed it to satisfy an insurer, an auditor, or a client requirement was, for the length of the affected range, in a worse position than they believed. Not an unprotected one, since the password still had to be known, but not the position described on the box either.
There is precedent inside this same plugin, and it is close enough to be instructive. In November 2024 the project shipped a fix for CVE-2024-10924, a 9.8 rated AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which NVD describes as “improper user check error handling in the two-factor REST API actions” that made it “possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, when the ‘Two-Factor Authentication’ setting is enabled.” Versions 9.0.0 through 9.1.1.1 were affected. That one required no password at all. Today’s is narrower and less severe, but it is the second authentication defect in two years in the same subsystem, which suggests the two-factor code path deserves attention rather than a single fix.
The twelve-day gap between the fix and the record is where a reader’s operational attention belongs. The order — patch first, disclosure later — is correct, and it is what coordinated disclosure looks like from the outside. But a fix nobody can identify as a fix has a shorter reach than one that is labeled. “Prevented a bug that incorrectly changed the 2FA status from active to open” is an accurate sentence. It is also a sentence that a site owner reading a September 1 update notice, deciding whether to apply an update to a production site on a Tuesday, would reasonably file under cosmetic. Nothing in it says an unauthenticated request could cause the change, and nothing in it says the consequence was a lost second factor.
That matters less for this plugin than it would for most, because a security plugin is one of the categories site owners most often leave on auto-update, and 9.8.1 has had twelve days to propagate. A large share of the three million installations are very likely already patched, and nobody should be told to panic. But auto-update is a setting, not a guarantee. The sites least likely to have it on are the ones running a managed stack with pinned versions, a staging-to-production promotion process, or a maintenance contract that batches updates monthly — which is to say, disproportionately the sites with real users and real administrator accounts.
The affected range’s floor is the remaining loose thread. Ranges in WordPress plugin records usually begin at 0 or at the release that introduced a feature; this one begins at 9.5.10.1, a maintenance-level version. The record does not explain it, and the plausible reading — that the email two-factor enrollment state was reshaped in that release and the missing check came with it — is an inference, not something either source states.
What to do
- Confirm the installed version, do not assume it. In Plugins, Really Simple Security should read 9.8.1 or later. Anything from 9.5.10.1 up to 9.8.0 inclusive is in the affected range. On a fleet,
wp plugin get really-simple-ssl --field=versionacross sites answers this faster than clicking through. - If the version is older, update. The fix has been available since September 1, 2026, there is no interim mitigation published by either source, and no workaround is described in the record.
- Check whether auto-updates are actually on for this plugin, rather than assuming they are because they are on somewhere. A site that was behind on this one is probably behind on others.
- Treat known-password accounts as the exposure. If any administrator on an affected site has a password that appears in a credential dump, is reused elsewhere, or predates a known incident, rotate it — updating the plugin restores the second factor but does not undo a session obtained before the update.
- Look for the signature of use. An account whose email two-factor enrollment moved from configured back to unenrolled without the user doing it is the artifact worth searching for in logs and in the plugin’s own user records.
- No exploitation has been reported, by WPScan, by the vendor, or in the NVD record. This is a patch-soon item, not a fire.
Sourcing note
Checked: the NVD record for CVE-2026-89080, read directly from the NVD API, for the description, score, vector, weakness, timestamps, references, and affected version range. The WPScan advisory referenced by that record, for its title, publication date, credited researcher, and fixed version. The plugin’s WordPress.org listing, for the active-installation figure, current version, and changelog entries for 9.8.1 and 9.8.0. The NVD record for CVE-2024-10924, read directly, for the 2024 background quoted above rather than relying on secondary accounts of it.
Conflicting dates, shown as conflicting: WPScan dates its advisory September 11, 2026; the CVE record reached NVD on September 13, 2026. Both are reported above rather than reconciled.
Unresolved: why the affected range begins at 9.5.10.1; the reading offered above is an inference and is labeled as one. Whether the other two security lines in the 9.8.1 changelog have records of their own — none appeared for this plugin in the same WPScan batch, which is not the same as none existing. The installed-base figure is WordPress.org’s own rounded “3+ million” and no more precise number is available. There is no vendor security advisory separate from the changelog, and none is referenced by the record.