If you run a WordPress site, this is one of those weeks worth pausing your to-do list for. The latest roundup of wordpress critical vulnerabilities october 2026 shows 11 critical-severity flaws disclosed between September 25 and October 2 — and, as of the report, not a single one has a patch. Two of them can hand an attacker your admin account without them knowing your password. This post walks through all 11 flaws, explains exactly what “no patch” means for you, and gives you a five-step action plan to keep your site safe today.
Quick answer: WPSentry’s September 25–October 2, 2026 vulnerability report lists 200 disclosed WordPress vulnerabilities — 11 rated critical — with zero patched. The most dangerous are authentication bypasses in DevKit Pro (≤2.3.0) and Divi Membership (≤2.3.0) that can grant an attacker administrator access, and arbitrary file uploads in Request a Quote for WooCommerce (≤2.9.2) and Ultra Addons for Contact Form 7 (≤3.5.50). Because no patches exist yet, updating will not help — the only protection is to disable, uninstall, or restrict access to the affected component.
The 11 critical vulnerabilities at a glance
The WPSentry WordPress Vulnerability Report for September 25 – October 2, 2026, which aggregates the NIST National Vulnerability Database, Wordfence Intelligence, and WPSentry’s own scanning data, disclosed 200 vulnerabilities in that single week: 11 critical, 65 high, 116 medium, and 8 low. The headline is the patch column: zero patched.
Here are all 11 criticals, straight from the report:
| Product | Vulnerability type | Affected versions | Status |
|---|---|---|---|
| DevKit Pro | Authentication bypass → admin account takeover | ≤2.3.0 | No patch |
| Divi Membership | Authentication bypass | ≤2.3.0 | No patch |
| Request a Quote for WooCommerce | Arbitrary file upload | ≤2.9.2 | No patch |
| Ultra Addons for Contact Form 7 | Arbitrary file upload | ≤3.5.50 | No patch |
| miniOrange OTP Login, Verification and SMS Notifications | Authentication bypass | ≤5.5.5 | No patch |
| Ultimate Multisite | Authentication bypass | ≤2.15.0 | No patch |
| LatePoint (Appointment Booking) | Arbitrary shortcode execution | ≤5.7.0 | No patch |
| Super Forms – Drag & Drop Form Builder | Privilege escalation | ≤6.3.316 | No patch |
| Super Forms – Drag & Drop Form Builder | Directory traversal | ≤6.3.316 | No patch |
| BackupSheep WordPress Backup Plugin | Integration key validation flaw | ≤2.3.0 | No patch |
| Zella Theme | Font upload action missing capability/nonce check | ≤2.6.3 | No patch |
Notice something: four of the eleven are authentication bypasses — flaws where the normal login rules simply don’t apply — and two are arbitrary file uploads, the classic route to full site takeover. These aren’t theoretical “an admin with bad intentions could…” issues. Several of these are exploitable by anyone who can reach your site.
What “no patch” actually means — and why updating won’t save you
When a vulnerability is disclosed and the vendor ships a fix, your job is simple: update. But when the report says “no patch”, the usual playbook breaks down. Here’s the uncomfortable truth:
- Updating the plugin will not fix it — because there is nothing newer to update to. The vulnerable code is still the current code.
- Your site stays exposed until the vendor releases a fixed version, for as long as the vulnerable component is installed and active.
- Attackers read these same reports. Disclosure windows with no patch are exactly when automated scanning and mass exploitation ramp up.
So “no patch” doesn’t mean “not a problem yet.” It means the burden of defense shifts entirely to you: disable the vulnerable feature, uninstall the component, restrict who can reach it, or put a web application firewall (WAF) with virtual-patching rules in front of it. The report’s own recommendations — update immediately, enable auto-updates, remove unused plugins, monitor regularly — still matter, but for these 11 flaws the operative advice is remove or restrict, not update.
The two flaws that can hand attackers your admin account
DevKit Pro (≤2.3.0) and Divi Membership (≤2.3.0) both carry authentication bypass flaws. In plain language: under certain conditions, a visitor can authenticate as an administrator without knowing any credentials. From there, the attacker owns the site — they can install plugins, modify theme files, create users, and lock you out. This is the worst class of web vulnerability, and it sits in two different plugins in the same week.
One important distinction: Divi Membership is a separate membership plugin — it is not the Divi theme. If you run the Divi theme (WPPlugg serves Divi theme 5.14.0) and not the Divi Membership plugin, this particular flaw does not apply to you. Check which one you actually have installed before panicking.
miniOrange OTP Login (≤5.5.5) and Ultimate Multisite (≤2.15.0) round out the auth-bypass group. The miniOrange one is especially awkward: it’s a login security plugin — the thing you installed to make logins safer — carrying a bypass of its own. Ironic, but it happens.
Arbitrary file uploads: the site-takeover combo
Request a Quote for WooCommerce (≤2.9.2) and Ultra Addons for Contact Form 7 (≤3.5.50) both allow arbitrary file uploads. This is the flaw class that keeps security teams up at night: if an attacker can upload an arbitrary file to your server, they can typically upload executable code and take full control of the site.
The Ultra Addons case is worth a second look because of how many sites it touches. Ultra Addons is an add-on pack for Contact Form 7, one of the most installed WordPress plugins of all time. The core Contact Form 7 plugin itself is not flagged in this report — only the Ultra Addons extension, versions 3.5.50 and below. If you use Contact Form 7 with Ultra Addons, disable or uninstall the add-on until a fixed version ships; plain Contact Form 7 can stay.
A similar note applies to Request a Quote for WooCommerce (≤2.9.2): this is a specific quote-request plugin, distinct from YITH’s Request A Quote product. Verify the exact plugin name on your Plugins screen — “similar name” is not the same as “affected.”
The rest of the critical list, briefly
- LatePoint (≤5.7.0) — arbitrary shortcode execution in the appointment-booking plugin. If you run LatePoint 5.7.0 or older, restrict the plugin’s frontend access or disable it until patched. (Good news for WPPlugg users below.)
- Super Forms (≤6.3.316) — two criticals in one plugin: privilege escalation and directory traversal. Either one alone is serious; together they make this one of the riskier entries on the list.
- BackupSheep (≤2.3.0) — an integration-key validation flaw in a backup plugin. Backup tools run with broad permissions by nature, which makes flaws in them disproportionately dangerous.
- Zella Theme (≤2.6.3) — a font-upload action missing capability and nonce checks. Theme vulnerabilities are rarer than plugin ones, but they affect every page of your site by definition.
What about WPPlugg users?
If you download plugins from WPPlugg, here’s where you stand on this report:
- LatePoint: WPPlugg serves LatePoint 5.7.3 — that’s above the flagged ≤5.7.0 range. Note the careful wording: the report confirms the flaw in versions up to 5.7.0; 5.7.3 sits above that range, but the report doesn’t confirm whether 5.7.3 itself contains a fix. It’s outside the flagged range, not a declared patch.
- The other 10 criticals are not in the WPPlugg catalog — DevKit Pro, Divi Membership, Ultra Addons for Contact Form 7, miniOrange OTP, Request a Quote for WooCommerce, BackupSheep, Super Forms, Ultimate Multisite, and Zella Theme are none of them served by WPPlugg.
- A note on Motors: the same report flags a high-severity blind SQL injection (≤1.4.109) in the Motors companion plugin line. WPPlugg serves the Motors theme (5.6.103) — a different product from the affected component.
Security advisories are becoming a regular beat here — see our recent coverage of the Unlimited Elements XSS vulnerability (CVE-2026-103344) for the same drill applied to an Elementor add-on. When a flaw lands in something WPPlugg serves, we say so; when it doesn’t, we say that too.
What to do today: your five-step action plan
- Inventory. Go to Plugins → Installed Plugins and Appearance → Themes. Search for each of the 11 names above. Most sites will find zero matches — that’s the best outcome.
- Disable or uninstall matches. If you find an affected version and the component is non-essential, deactivate and delete it now. Deleting removes the vulnerable code entirely; deactivating at least takes it out of the request path.
- Restrict what you can’t remove. If the vulnerable plugin runs your business (a booking flow, a membership gate), restrict access: limit the affected functionality to logged-in roles only, block suspicious request patterns, and consider a WAF with virtual-patching rules for the specific flaw class.
- Back up before you touch anything. A full backup (files + database) before disabling or removing components means you can roll back if removing something breaks your site.
- Watch for the patch. These vendors will ship fixes — likely within days for flaws this severe. When a new version lands, update immediately, then re-enable. Until then, “no patch” means “no update,” so don’t let the Updates screen lull you into thinking you’re covered.
How to check your installed plugin version
Go to Plugins → Installed Plugins in your WordPress dashboard. The version number appears directly under each plugin’s name — for example, “Version 2.9.2”. Compare it against the affected ranges in the table above: if your installed version is equal to or lower than the flagged maximum, you’re in the affected range. For themes, the same applies under Appearance → Themes → Theme Details. Do this for every item on the list; it takes under five minutes.
When patches land
We’ll update this post as fixed versions ship. The general rule for flaws this severe: vendors tend to move fast, but “fast” in plugin-land can still mean days. In the meantime, treat every day the vulnerable code stays active as another day attackers have had to build exploits from the public disclosures. Remove or restrict first; update the moment a fix exists.
Running LatePoint? Get a copy above the flagged range
WPPlugg serves LatePoint 5.7.3 — above the ≤5.7.0 versions flagged in the October 2026 vulnerability report — as a GPL-licensed download. If your site runs an older, flagged copy, grab the newer release and close this gap.
What does “no patch” mean in a vulnerability report?
It means the vendor has not yet released a fixed version at the time of the report. Updating the plugin or theme will not protect you, because the current version — the one you’d be updating to — still contains the vulnerable code. Your options are to disable or uninstall the component, restrict access to it, or shield it with a WAF virtual-patch until the vendor ships a fix.
Am I affected if I run LatePoint 5.7.3?
The report flags LatePoint versions up to and including 5.7.0 for arbitrary shortcode execution. Version 5.7.3 sits above the flagged range, so it is not one of the confirmed-affected versions — but the report does not confirm that 5.7.3 itself contains a fix either. Treat it as outside the flagged range, keep an eye out for a vendor security release, and follow the same disable-or-restrict precautions if your situation is uncertain.
Is the Divi theme affected by the Divi Membership flaw?
No — Divi Membership is a separate membership plugin, not the Divi theme. The authentication bypass in the report applies only to the Divi Membership plugin (≤2.3.0). If you run the Divi theme without the Divi Membership plugin, this flaw does not apply to you. Always check the exact plugin name on your Plugins screen rather than assuming from a similar name.
How do I check which version of a plugin I’m running?
In your WordPress dashboard, go to Plugins → Installed Plugins — the version number is printed directly under each plugin’s name. Compare it against the affected ranges in the table above. For themes, go to Appearance → Themes and open Theme Details. The whole check takes under five minutes.
What should I do with a vulnerable plugin my business depends on?
Don’t leave it fully exposed while you wait for a patch. Options: restrict the vulnerable functionality to trusted logged-in roles only, put a WAF with virtual-patching rules in front of the site, or temporarily replace the feature with an alternative. Back up (files + database) before making changes, and re-enable or update the moment the vendor ships a fixed version.
How will I know when patches are released?
Enable auto-updates for the affected plugins where possible, subscribe to the vendor’s changelog or security mailing list, and watch the WordPress dashboard Updates screen. For severe flaws like these, fixes typically land within days — but until one exists, assume the vulnerable code is still the current code and keep your mitigations in place.
