Four plugins. Four separate codebases. The same score at the top of each advisory: 9.8 out of 10.
At the start of October, security researchers disclosed critical authentication flaws in four unrelated WordPress plugins: DevKit Pro, Divi Membership, JSON API Auth and WPMobile.App. Each flaw, in its own way, lets a visitor with no account at all end up signed in as an administrator. No password guessing. No stolen credentials. The plugin itself hands over the keys.
Same-day clusters like this are rare. And they are awkward for defenders, because there is no single update to push. Each plugin has its own fixed version, its own maintainer, its own release rhythm. A site running two of the four needs two separate fixes before it is actually safe.
Four doors, four different locks picked
Start with DevKit Pro, a developer toolkit, affected in versions up to 2.3.0 and tracked as CVE-2026-14378. Its user-switching feature includes a switch-back handler meant to return an administrator to their original account. In the vulnerable code, that handler decides who you are by reading a cookie the visitor's own browser supplies. Set that cookie to an administrator's user ID, collect a nonce the plugin prints into the page footer for anyone who asks, and the handler will issue a full admin session. The identity check trusted the one value the attacker controls. A public proof of concept with mass-scan capability has already appeared, which turns a bad flaw into an assembly line.
Divi Membership, up to version 2.3.0, carries CVE-2026-19660. Its payment callback accepts an encoded parameter from the web address and, without checking with the payment provider that a real transaction happened, uses the user ID inside it to start a session. Encode an administrator's ID and the site logs you in as that administrator. One request is enough. Worse, the vulnerable code loads on ordinary front-end visits whether or not the site actually takes payments through that gateway, so switching the payment option off in settings does not close the hole.
JSON API Auth, up to version 3.1.2, is CVE-2026-97637, and its failure is a caching accident with teeth. The plugin's login endpoint puts a live signed-in cookie inside its response. A parent plugin caches responses using only the web address to tell them apart, without distinguishing a signed-in request from an anonymous one. So if an administrator has used that endpoint within the cache's 24-hour window, a later unauthenticated visitor asking for the same address can be served the cached response, admin cookie included. Our coverage of enterprise API security and broken access control describes exactly this family of mistake: an identity decision made once, then replayed for everyone.
WPMobile.App, up to version 11.82, rounds out the set as CVE-2026-94541. Sites that enable its mail-to-push feature copy outgoing email, including password-reset messages, into a push queue. The flaw lets unauthenticated visitors read entries from that queue. A password-reset link for an administrator, sitting in a queue anyone can query, is not a partial compromise. It is the whole account, one click later.
The clock is already running
Wordfence, the WordPress security firm whose research underpins much of the cluster reporting, blocked 137 attacks aimed at the WPMobile.App flaw in a single 24-hour period. That number covers one flaw, one defender's customer base, one day. Scanners do not wait for administrators to finish reading advisories, and the DevKit Pro proof of concept means the scanning can be automated across thousands of sites at once.
Context matters here, though. None of the four flaws had been added to CISA's Known Exploited Vulnerabilities catalog when the cluster was published, and for the JSON API Auth flaw, the CVE record's analysis notes no confirmed public exploit code so far, with a low exploitation-probability estimate. Those are not reasons to relax. KEV listing follows exploitation; it does not precede it. The gap between disclosure and listing is precisely the window in which patching is cheap.
There is also a sequencing problem that has nothing to do with any single site. When four critical flaws land together, the sites most at risk are the ones whose administrators learn about disclosures last: small publishers, local businesses, community organisations running a membership plugin here and a mobile app builder there. Their patching cycle is measured in weeks. The scanning cycle is measured in hours. Everything in the cluster reporting, from the blocked attacks to the ready-made scanning tool for DevKit Pro, points the same way: the attackers' timeline compressed years ago, and disclosure weeks like this one are where the gap shows.
WordPress sites have lived through this pattern before, usually one plugin at a time. When a national register loses data through a partner's legitimate access, as in the Denmark population register breach, the lesson is about trusted pathways. A plugin flaw is the same lesson at smaller scale: the trusted pathway is the code you installed yourself, and trust, once installed, rarely gets audited.
What an administrator actually has to do
The fixes exist. That is the good news, and it comes with version numbers, because updating to the wrong release is its own failure mode.
DevKit Pro is fixed in 2.3.1, and its developer recommends moving to 3.0.0 or later. Divi Membership is fixed in 3.0.0. JSON API Auth is fixed in 3.1.3. WPMobile.App is fixed in 11.85. A site is only covered when every affected plugin it runs reaches its patched version. Three out of four is not a statistic. It is an open door with better company.
Then comes the part site owners skip. Updating closes the flaw; it does not evict anyone who already used it. Administrators should look at their user lists for accounts they do not recognise, force password resets for administrator accounts, invalidate active sessions, and check for plugins or themes they did not install. An attacker who reached the dashboard even once had time to create a quieter way back in. Our reporting on enterprise ransomware defence and immutable backups makes the same point from the other end of an incident: recovery is much easier when a clean copy exists from before the intrusion.
If a plugin cannot be updated immediately, deactivating it is safer than leaving a known 9.8 in place, and firewall rules can blunt the known request patterns in the meantime. What does not work is hoping the site is too small to notice. The 137 blocked attacks were not aimed at famous targets. Mass scanning does not read your traffic statistics before knocking.
Where an update has to wait, there are partial shields, and partial is the word to hold onto. Firewall rules can be written against the known request shapes in this cluster: the switch-back call in DevKit Pro, the payment parameter in Divi Membership, the cached login endpoint in JSON API Auth, the push-queue query in WPMobile.App. Restricting the admin area to known IP addresses, where a site's workflow allows it, cuts the reachable surface further. Both measures buy hours or days. Neither changes the code that trusted the wrong input, which is why every compensating control is framed as a bridge to the update, not an alternative to it. The update is the fix. Everything else is a sandbag.
There is a quieter conclusion for the ecosystem. All four flaws are, at root, the same error wearing different clothes: software believing a claim about identity because checking properly was one step more work. A cookie believed. A payment parameter believed. A cached answer believed. A queue believed readable by whoever asks. WordPress powers a large share of the web, and its plugin model means that belief gets installed, site by site, by people who reasonably assumed someone else had checked. This week, in four places at once, nobody had.
Site owners who want a wider view of how disclosure pipelines are straining under automated reporting can read our coverage of Google pausing its open source bug bounty after a flood of AI-generated reports. The connection is real: defenders are short on time everywhere, which is exactly why a same-day pile-up of critical flaws is so hard to absorb. Patch the four. Audit the accounts. Then go back and ask the harder question, which is how many other plugins on the same sites are one disclosure away from the same week.
Why this bug class sits at the top of the pile
Security teams rank flaws by more than the number printed beside them. Plenty of vulnerabilities score high and still leave an attacker work to do: a foothold to deepen, a privilege to escalate, a second bug to chain. Authentication bypass skips the queue. The attacker arrives as a stranger and leaves as the most trusted account on the site, with the dashboard's full tooling available: file editors, plugin uploads, user management, settings that decide what visitors see and what search engines index.
The classifications underline the pattern. Three of the four are catalogued as improper authentication, the category for systems that fail to prove identity properly. The fourth is missing authorisation, a system that never asked whether the requester was allowed to see what it showed. Different labels. Same underlying habit of trusting first.
Detection after the fact is the uncomfortable part. An intruder holding real administrator credentials looks, in most logs, like an administrator. The cluster reporting warns that attackers who get in this way can plant backdoors, register rogue admin accounts and pull data while leaving thin forensic traces. That is why the response advice pairs patching with an audit rather than treating the update as the finish line. If the audit finds a user nobody created on purpose, the incident stops being a near miss and becomes a cleanup: sessions revoked, credentials rotated everywhere, installed code reviewed file by file, and the site's content checked for changes nobody approved.
Small sites feel this hardest, and not because they are careless. A one-person business cannot watch four disclosure feeds at once. It relies on auto-updates, on a host that flags critical flaws, on the reasonable assumption that a paid plugin's login-adjacent features were tested against the oldest trick in the book: a stranger claiming to be someone else. The start of October showed four separate codebases failing that test on the same day. The assumption is the vulnerability. The plugins were just where it surfaced.
Plugin flaws like these are usually found twice — once by researchers, once by scanners. The research side is struggling with volume of a different kind: Google paused its open-source bug bounty after a flood of AI-generated reports buried the reviewers. The scanning side has no such bottleneck, and nation-state groups running harvest-now, decrypt-later campaigns are exactly the actors with the patience to catalogue every unpatched site for later.
