117 Critical WordPress Plugin CVEs in October, Almost All Without a Login. Is One of Yours on the List?

Between October 1 and October 30, 2026, the National Vulnerability Database published 117 vulnerabilities in WordPress plugins with a CVSS score of 9.0 or higher. They are spread across 108 different plugins. The ones listed on WordPress.org have more than 3 million active installs between them, and the rest are premium plugins sold elsewhere, so the real number is higher.

The detail that matters most: 107 of the 117 need no account on the site. NVD rates them “privileges required: none”. An attacker does not have to log in, register, or trick an admin into clicking anything. A request to a public page or endpoint is enough.

October in Numbers

Sorted by what they let an attacker do, roughly:

• SQL injection (33). Read or change the database: user emails, password hashes, orders, form entries.
• Privilege escalation and authentication bypass (25). Become an administrator, or log in as someone else.
• PHP object injection (21). Feed the plugin crafted data that PHP turns back into objects. With the right code elsewhere on the site, this ends in code execution.
• Arbitrary file upload (19). Upload a PHP file, usually a web shell, and run it.
• Code or command injection (11). Run code on the server directly.
• File inclusion, path traversal and deletion (6). Read files such as wp-config.php, or delete them to force a reinstall.

None of the 117 is on CISA’s Known Exploited Vulnerabilities list yet. That list moves slower than attackers do. Plugin bugs this severe are usually scanned for within days of being published, because a working exploit can often be written from the patch itself.

The Biggest Plugins on the List

These are the most-installed plugins with a critical CVE published in October. Install counts come from WordPress.org and are rounded. “Current release” is the version on WordPress.org on October 30. If yours is at or above it, you are past the affected range.

Two of the seven perfect 10.0 scores are worth naming even though their install counts are small: AjaxLoadMore Cache (CVE-2026-61991, unauthenticated remote code execution, versions up to 3.1.1, published October 29) and WP Mailster (CVE-2026-111832, upload of a web shell, versions up to 1.9.1.0). When the result is a shell on your server, a small install base is no comfort.

This Is a Normal Month Now

October is not a record. June had 119 critical plugin CVEs and August had 120. So far in 2026 there have been 629, about 63 a month. Most WordPress sites run many plugins, so in any given month there is a real chance at least one of yours is on a list like this one.

The sites we scan bear that out. Of the WordPress sites run through our scanner in the three days before this post, about 4 in 10 showed at least one plugin with a known CVE. That is not a random sample of the web, but it is a lot of front doors left open.

What the Check Can and Cannot See

The scanner looks at your site from the outside, the way an attacker’s first request does. Plugins give themselves away through the files they load: every script or stylesheet under /wp-content/plugins/<name>/ names the plugin, and many add their version to the URL (?ver=4.4.10) or put it at the top of the file. The scanner reads all of them and matches each plugin and version against a local copy of the National Vulnerability Database.

• A plugin with a version on show is checked against every CVE on record for it. If it is in an affected range, you get an Exposure finding with the CVEs, the worst score and the version to update to.
• A plugin without a version is listed as “seen, version not shown”. The check cannot tell if it is patched and will not guess. Check those in your dashboard.
• A plugin that loads nothing on your public pages (an admin-only tool, a form handler on a page we did not scan) is invisible from outside. Attackers usually probe for those directly, so a clean result is not the same as a full inventory.

What to Do

• Update every plugin today. In the dashboard, go to Plugins and select all, then Update. For the plugins in the table above, check that you end up at or above the current release.
• Turn on auto-updates for plugins. It is a per-plugin switch on the Plugins screen. The plugins most at risk are the ones nobody remembers installing.
• Delete what you do not use. A deactivated plugin’s files are still on the server, and it stops getting your attention for updates.
• Check premium plugins by hand. Plugins bought outside WordPress.org often update only with a valid license key. An expired license quietly means no security fixes.
• If you ran an affected version, look for signs of use. New administrator accounts, PHP files in wp-content/uploads, and unfamiliar scheduled tasks are the usual traces.
• Rescan. The Exposure finding should clear.

Next Month’s List Is Already Being Written

Every domain in an InternetSecure account is scanned daily. When a plugin your site shows gets a new CVE, the change lands in your alert digest, Slack, JIRA or Linear the same day, with the version to move to. When you update and it clears, you hear about that too. You do not have to read NVD every morning to know whether this month’s list has your name on it.

Create a free account to monitor your domains, or run a one-off check from the homepage scanner.

Method: CVEs published in NVD from October 1 to 30, 2026, with a CVSS base score of 9.0 or higher and a match against a WordPress plugin. “No login” means the NVD CVSS vector says privileges required: none. Categories are grouped from each CVE’s description. Install counts are WordPress.org’s rounded active-install figures for the 82 plugins listed there.