24 WordPress plugin flaws: two-factor authentication itself can be bypassed (CVE-2026-15372)

Twenty-four WordPress plugin vulnerabilities were published together on 5 August 2026. The heaviest finding is that two plugins whose entire job is to add two-factor authentication contain flaws that let that second factor be bypassed.

One is WP 2FA (CVE-2026-15372, rated 8.1), installed on 100,000+ sites. The other is miniOrange 2FA (CVE-2026-16036, rated 7.5). In both cases, the second step stops working once the password is known. A mechanism whose whole purpose is to hold the line after a password leaks becomes useless at exactly the moment the password leaks.

The highest score in the batch belongs elsewhere: CVE-2026-16940 at 10.0, the maximum. Anyone, without logging in, can delete any file on the server.

Of the 24, 11 need no login at all. And three cannot be updated from the WordPress dashboard — one of them because distribution has been withdrawn entirely and no fix exists.

What is affected, and what to do

All 24 are listed below so you can check your own site, ordered with the no-login-required entries first. Install counts are approximate figures from the official WordPress.org API, checked on 5 August. Scores are the values assigned by WPScan as the CNA — none of these 24 carries a score in NVD yet, and we have not filled that gap with numbers of our own.

The widest install base here is GDPR Cookie Compliance at 300,000+ sites, followed by WP 2FA and Orbit Fox at 100,000+ each. The 10.0 entry, Custom Fields for WooCommerce, sits at around 600. Reach and severity do not line up here either.

Who goes after this, and what gets lost

The people who pick up this batch are attackers who already hold somebody's password. They buy leaked combinations in bulk and work through them. Reaching the login screen is easy; being stopped there by two-factor authentication has been the normal outcome.

What today's disclosures show is that that final wall was, under the right conditions, not standing. Sites that deploy two-factor authentication are precisely the ones that reason "a leaked password is survivable." That assumption breaks here.

What is lost is the administrator account itself. From inside the dashboard, posts can be rewritten, new administrators added, and the whole site rebuilt. Member records on a membership site, orders and delivery addresses on a shop, all sit within reach. Two-factor authentication is insurance against a password leak. If the insurance does not pay out, password hygiene becomes the last line. We have covered a related case, a takeover requiring no password at all in miniOrange's SSO plugin.

The two-factor plugins were not protecting two-factor

CVE-2026-15372: WP 2FA simply did not verify the second factor

Installed on 100,000+ sites, the most widely deployed two-factor plugin in this batch. Rated 8.1.

The substance: when one of the supported methods is selected at login, the second factor is not validated at all. An attacker who knows the password bypasses two-factor entirely and gets in. Administrator accounts included. WPScan's record describes the route as a two-factor bypass via the Passkeys provider.

The fix is 4.1.0, shipped on 24 July. The vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — AC:H, high attack complexity, reflecting the requirement to hold the password up front.

CVE-2026-16036: miniOrange 2FA let the second factor be re-pointed

Installed on 10,000+ sites, rated 7.5. The mechanism differs.

During the pre-login two-factor challenge there is a point at which a second factor gets configured. That factor was not checked against the one already registered on the target account. An attacker holding the password can therefore re-point the victim's second factor at a destination they control, take the code that arrives there, complete the challenge, and take the account — administrators included.

The fix is 6.2.7; the current release is 6.2.8 (24 July).

Both share one precondition: the attacker must already know the password. Put the other way round, a password that has not leaked keeps these two out on their own. But if any user reuses a combination that leaked elsewhere, the precondition is trivially met. Sites running two-factor authentication are the ones that should patch these first.

The 10.0 entry is not in the official directory

CVE-2026-16940: delete any file on the server, no login required

The only maximum score in the batch, 10.0. The plugin is "Custom Fields for WooCommerce" by Addify, which adds fields to checkout forms; versions below 1.5.1 are affected.

The path of the file to delete is not validated, so an unauthenticated attacker can remove arbitrary files from the server. WPScan names wp-config.php explicitly as an example. Delete that one file and WordPress reverts to an un-installed site. Point it at a database the attacker controls, and the site becomes theirs.

Distribution is the awkward part. This plugin is not in the WordPress.org directory. It is a paid plugin sold through the WooCommerce marketplace and the developer's own store, which means it does not appear in the dashboard's updates panel automatically. On sites where no licence key was registered, it may have been sitting unpatched. If that sounds familiar, log in to wherever you bought it and pull 1.5.1.

Note that WordPress.org hosts an entirely unrelated plugin also called "Custom Fields" (withdrawn back in 2019). Do not confuse the two; the affected one is the WooCommerce plugin.

The most damaging of the 11 that need no login

CVE-2026-15360: reading the database through Ajax Load More, one character at a time

30,000+ installs, rated 8.6. The plugin powers "load more posts" behaviour. Database commands can be injected without logging in. The technique infers content from how long the response takes, character by character — slow, but reliable. Fixed in 8.0.1.

CVE-2026-16981 / CVE-2026-16993: DHL shipping labels can be pulled from outside

These two are the most tangible personal-data exposure in the batch. The plugin generates shipping labels for WooCommerce; 4,000+ installs.

CVE-2026-16981 exposes stored labels under sequential identifiers that can be downloaded one after another without any login. A shipping label carries the recipient's name and full postal address. Increment the number and the site's customer list comes out in order.

CVE-2026-16993 concerns how that storage is protected. Access was blocked using .htaccess, which does nothing on server setups that ignore it, such as nginx — leaving the directory directly reachable. Both are fixed in 4.0.1.

CVE-2026-16604: Passster wrote the protected content into the HTML

This plugin puts passwords on posts, and three entries landed against it. The clearest is CVE-2026-16604: the protected body text was written into the page HTML before the password was ever checked. Viewing source is enough to read it.

The other two differ only in entry point. CVE-2026-16603: category-level protection is not applied to WordPress's own data API, so body, title and excerpt come out. CVE-2026-16602: the plugin's own verification endpoint exposes draft, private and pending posts (this one only where a captcha provider is configured). All three are fixed in 4.3.6.

CVE-2026-16736: accounts get created even with registration disabled

A membership registration plugin with 50,000+ installs. The "registration closed" setting can be bypassed, and accounts created without logging in. What gets created is a low-privilege account — but that is the foothold the other entries here, several of which only need subscriber access, are waiting for. Fixed in 5.2.6.

CVE-2026-16613: the 300,000-site cookie banner as a forced-logout tool

The most widely installed plugin in the batch at 300,000+ sites, but rated only 4.3. Getting someone to follow a crafted link can force a visitor to log out or wipe their stored consent record. It does not lose you the site. Fixed in 5.1.0.

Three that cannot be updated

Three of the 24 will never show up in the dashboard's updates panel, for three different reasons.

The worst of the three is WP Custom HTML Page. Its WordPress.org page states that it "has been closed as of June 21, 2026" pending a full review, and it cannot be downloaded. The last release was version 0.6.2, six years ago, and WPScan's record lists no fixed version. If you run it, there is nothing to upgrade to — deactivate and delete is the only option.

A note on Zportals as well. The latest release we could find on the vendor's own site is 6.2.0 (29 March 2026), with no sign of the 6.3.4 line that WPScan names as fixed. We could not verify that the fixed version exists. If you run it, ask the vendor directly.

Is any of this being exploited

No reports of exploitation for any of the 24 as of 5 August. We compared all 1,660 entries in the 4 August KEV catalogue maintained by CISA: none of these 24 appears. Our CISA KEV dashboard explains how to read that catalogue.

No proof-of-concept code has been published either. WPScan holds proof-of-concept material back until fixes have had time to propagate. Which also means it will be published eventually. Now is the easy window.

Note also that none of these 24 carries a score in NVD — all were still at the intake stage on 5 August. Every number in this article comes from WPScan as the assigning body. If NVD later adds its own assessment, those numbers can move. That is not hypothetical: on Apache Traffic Server, the vendor's scores and NVD's diverged by more than three points.

What to do

Open the updates panel first and apply anything from the table above. Twenty-one of the 24 have fixes distributed through WordPress.org, so updating settles those.

Sites running two-factor authentication should take WP 2FA and miniOrange 2FA first. These two undermine the "we have 2FA, so we are fine" assumption itself. While you are there, check whether administrator passwords are reused anywhere else — both entries depend on the password already being known.

If you run a WooCommerce store, take inventory of paid plugins installed from outside the official directory. The 10.0 entry is exactly that case, and no update notice will appear in your dashboard.

If you run WP Custom HTML Page, remove it. There is no fix and no distribution. A separate batch was published the same day — those ten all have released fixes — and checking both leaves fewer gaps.

Summary

Twenty-four WordPress plugin vulnerabilities were published on 5 August 2026. The striking part is that two plugins built to add two-factor authentication contain flaws that bypass it. WP 2FA (100,000+ sites) did not validate the second factor; miniOrange 2FA (10,000+ sites) allowed it to be re-pointed. Both require the password to be known already — which is precisely the situation two-factor authentication exists to cover.

The single 10.0 is Custom Fields for WooCommerce, where any file on the server can be deleted without logging in. That plugin ships from outside the official directory, so no update prompt appears in the dashboard.

Eleven of the 24 need no login, three cannot be updated from the dashboard, and for one of those no fix exists at all. Nothing has been reported as exploited and no proof-of-concept code is out. If you are going to act, act now.

Frequently asked questions

Should I stop using two-factor authentication?

No. These are flaws in specific versions of specific plugins, not in the concept. Update to the fixed release and keep using it.

Am I safe if my password has not leaked?

For the two 2FA entries, yes. But if any user reuses a combination that leaked from another service, the precondition is met whether you know it or not. And 11 of the 24 need no password at all.

Can I defer the low-scoring ones?

Judge by what is installed on your site rather than by the number. Here a 4.3 sits on 300,000 sites and the 10.0 sits on roughly 600. Working strictly down the scores diverges from reality.

What about WP Custom HTML Page, which has no fix?

Deactivate and delete it. Distribution stopped on 21 June 2026 and the last release was six years ago. Finding a replacement is the faster path.

Why are there two WordPress articles today?

Different assigning bodies. The other batch of ten came from Wordfence and every entry already had a fix. These 24 come from WPScan: 11 need no login and three cannot be updated. No plugin appears in both.

References

• ▸WPScan - WP 2FA < 4.1.0 Two-Factor Authentication Bypass via Passkeys Provider (CVE-2026-15372)
• ▸WPScan - miniOrange 2FA < 6.2.7 2FA Bypass via Password-Only Second-Factor Rebinding (CVE-2026-16036)
• ▸WPScan - Custom Fields for WooCommerce < 1.5.1 Unauthenticated Arbitrary File Deletion (CVE-2026-16940)
• ▸NVD CVE-2026-15372 (WP 2FA)
• ▸NVD CVE-2026-16036 (miniOrange 2FA)
• ▸NVD CVE-2026-16940 (Custom Fields for WooCommerce)
• ▸NVD CVE-2026-15360 (Ajax Load More)
• ▸NVD CVE-2026-16942 (WP Custom HTML Page — no fix available)
• ▸WordPress.org - WP Custom HTML Page (closure notice)
• ▸WordPress.org plugin directory (install counts, current versions and update dates retrieved 5 August 2026)
• ▸CISA Known Exploited Vulnerabilities Catalog (4 August 2026 version, all 1,660 entries compared)
• ▸WPScan vulnerability disclosure policy (handling of proof-of-concept material)