CVE-2026-75800 reached the National Vulnerability Database at 6:16 a.m. UTC on September 12, 2026 carrying a 9.8, and the plugin it describes was already gone from the WordPress plugin directory — closed on September 4, with no fixed version to move to.
What happened
WPScan published an advisory on September 10, 2026 titled “Frontegg SAML SSO <= 1.0.1 – Unauthenticated Account Takeover via Unverified SAMLResponse.” The CVE record built from it, CVE-2026-75800, was published to NVD two days later at 6:16 a.m. UTC on September 12 and last modified at 4:16 p.m. UTC the same day. Its description is a single sentence: “The Frontegg SAML SSO WordPress plugin through 1.0.1 does not verify the signature or issuer of SAML authentication responses before establishing a session, allowing unauthenticated attackers to log in as any user, including administrators, as well as to create arbitrary accounts.”
Two checks are named as absent, not one. The plugin does not verify the signature on the SAML response, and it does not verify the issuer. Either omission alone is an authentication bypass. Together they mean the service provider treats an XML document handed to it by an unauthenticated client as proof of who sent it.
The WPScan entry gives the affected range as 1.0.1 and earlier and, under its fixed-version field, the value “No known fix available.” The record in NVD expresses the same range as version 0 through 1.0.1 under semantic versioning, which is every release the plugin has ever shipped. Version 1.0.1 is also the newest: the directory listing shows the plugin last updated roughly a year ago. The finding is credited to the researcher moonge, and WPScan states that the proof of concept will be published on October 1, 2026.
The 9.8 is WPScan’s own score, not NIST’s. In the NVD record the CVSS v3.1 metric appears as a secondary entry sourced to WPScan’s CNA identifier, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and the weakness classified as CWE-287, improper authentication. NVD’s own vulnStatus is still Received, so there is no NIST analysis and no primary score. No privileges, no user interaction, network reachable, low complexity, high impact across the board.
The plugin itself is no longer distributed. Its page in the WordPress plugin directory now carries the notice: “This plugin has been closed as of September 4, 2026 and is not available for download. This closure is temporary, pending a full review.” That closure predates the advisory by six days and the CVE record by eight. Whether the two are connected is not stated anywhere we can read, and we are not going to assume it.
One number is missing. The directory suppresses the active-installation figure for closed plugins, so the page that would size this exposure shows nothing. Treat the scale as unknown rather than small.
Why it matters
Signature verification is not a hardening option in SAML. It is the whole mechanism. A SAML response is a plain XML document that travels through the user’s browser, which means the person being authenticated is also the courier. The only thing that distinguishes an assertion minted by the identity provider from one typed by the visitor is the cryptographic signature over it, checked against a certificate the service provider already trusts, from an issuer the service provider already expects. Remove both checks and the login form has been replaced by a text field in which the visitor writes down which account they would like to be.
That is why the “create arbitrary accounts” clause in the description deserves more attention than the account-takeover headline. A session can be invalidated. A provisioned user cannot be un-provisioned by uninstalling the thing that provisioned it. If this plugin will create a WordPress user for a subject named in an assertion it never verified, then any site that ran it may be carrying real account rows that an attacker authored, and those accounts keep working after the plugin is deactivated, deleted, and forgotten. Removal closes the door. It does not evict anyone who already walked through.
This is the fourth SAML verification failure Severity Daily has covered in eleven days, and the shape repeats with a consistency that has stopped looking like coincidence. On September 2 it was F5’s njs access control failing open and nginx-saml parsing attacker XML before checking the signature. On September 6 it was MojoX::Authentication building a SAML binding with no trust anchor at all. On September 10 it was passport-saml-encrypted verifying signatures only when an optional certificate was configured, with the project’s own README example leaving it out. In each case verification was implemented as configuration — something the integrator could supply, or could forget — rather than as a precondition the code refuses to proceed without. Here, by WPScan’s account, it was not implemented at all.
The ordering of events is its own lesson. The first public signal about this plugin was not an advisory; it was the plugin quietly disappearing from the directory on September 4. Nobody monitors a plugin page for absence, and nothing about a closure tells an operator whether the reason was a security report, a guideline violation, a trademark complaint, or an unresponsive author. Meanwhile the code keeps running everywhere it is already installed, because closing a directory listing stops distribution and nothing else. For eight days, the only people who could act on this were the ones who had happened to notice a missing page.
The remediation posture is also different from the one most vulnerability workflows assume. A normal high-severity WordPress advisory ends with a version number, and the work is scheduling the bump. Here there is no version number, and there never will be unless the author returns: the plugin is closed, so even a fix could not reach sites through the update channel while the closure stands. The action is removal, and removal of a single sign-on integration is not a routine change. It deletes an authentication path. Any organization whose users reach WordPress only through Frontegg has to stand up a replacement before it can take the vulnerable one away, which turns a delete into a project with a dependency.
Finally, there is a dated clock on this, even though no federal directive is involved. WPScan says the proof of concept publishes on October 1, 2026. That is nineteen days from today, and it is the interval in which an organization has to find every affected install, plan a cutover, and audit for accounts that should not exist. A private disclosure deadline is not a remediation deadline, but for a flaw with no patch it functions as one.
What to do
Inventory first. Look for the plugin folder wp-content/plugins/frontegg-saml-sso, or search your WordPress fleet for the slug frontegg-saml-sso. Every version is affected: the record’s range runs from 0 through 1.0.1, and 1.0.1 is the last release, so there is no “patched” build to look for and no version comparison to do. Presence is the finding.
There is no fixed version. Deactivate and delete the plugin. Before you do, confirm whether any accounts depend on it as their only login path, and provision an alternative — a maintained SAML service provider, or local credentials with multi-factor authentication — so that removal does not lock out administrators.
Then audit for what may already be there. List every user sorted by registration date and look for accounts nobody recognizes, paying particular attention to the administrator role. Compare WordPress login activity against your identity provider’s own sign-in logs for the period the plugin was installed: a WordPress session with no corresponding authentication at the identity provider is the signature of this class of flaw. Because the description says accounts can be created, the durable artifact to hunt for is a user row, not a session.
Then rotate. Force a password reset for every administrator, invalidate active sessions, and review application passwords and API keys issued during the window. On multisite, check super-administrator assignments across the network too.
Mark October 1, 2026 on the calendar as the date the exploitation details become public, and treat any site still carrying the plugin on that date as exposed to a published technique rather than a described one.
Sourcing note
Checked: the WPScan advisory for CVE-2026-75800 at wpscan.com/vulnerability/be658aa5-8f7f-4938-bf13-b2e6ed3dcf89/, which is the source of record for the CVE and the origin of the 9.8; the NVD record at services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-75800, read for the description, the CVSS metric and its source, the CWE, and the affected range; and the plugin’s page in the WordPress plugin directory, read for the closure notice quoted above.
Could not reach: the WordPress.org plugin information API, which is disallowed to automated fetching from here, so the active-installation count is unavailable from any primary source and this story does not estimate it. We found no statement from Frontegg about the plugin or the vulnerability, and no vendor advisory exists that we could locate.
Unresolved: whether the plugin is published by Frontegg Ltd. or by a third party using the vendor’s name, which the closed directory page no longer displays; whether the September 4 closure was prompted by this report or by something unrelated; and how many sites are affected. NVD has not completed its own analysis, so the 9.8 remains a single-source score from the reporting CNA rather than a NIST-confirmed one. No exploitation has been reported by any source we checked. cisa.gov returns 403 to automated fetching, so KEV status was checked through NVD’s republication of CISA’s fields, which carries none for this record.