WordPress Plugin Vulnerabilities, Q3 2026: What Got Exploited, and What the Bots Tried on Our Own Sites

Between July and September 2026 the WordPress attacks that mattered were not spread across thousands of plugins. Three WordPress core flaws and one Elementor Pro bug were exploited at scale, and most of them within hours of the patch. The only WordPress entries CISA added to its list of exploited vulnerabilities in the quarter were core: the wp2shell pair in July and CVE-2026-87902 in September.

The bots at our own door looked different. On the WordPress sites we run, Wordfence blocked 41,001 brute-force attempts in one month on a single shop, the firewall caught probes for plugins that were never installed, two of them from 2019, and the login the bots worked hardest on was not admin. It was the account our own AI publishing agent uses, because WordPress had printed its username in the RSS feed.

This is the first of a quarterly series. The market facts come from CISA, NVD, Patchstack, VulnCheck and wordpress.org, with the source quality noted where it matters. Our own numbers were measured read-only on 20 October 2026 with wp-cli on our production K3s cluster. Client sites are anonymised.

Q3 2026 at a glance

What actually got exploited in Q3 2026?

Sources: the VulnCheck wp2shell analysis, the WordPress 7.0.2 release note, Patchstack on CVE-2026-87902, Patchstack on the Elementor Pro flaw, NVD, and the CISA KEV feed. The Wordfence attack counts reached us through press coverage, not a Wordfence page, so treat them as orders of magnitude.

Two patterns sit in that table. The first is speed: for three of the four, attacks started on the day the fix shipped. Patchstack’s State of WordPress Security in 2026 measured the weighted median time to mass exploitation at 5 hours for the heavily exploited flaws of 2025. A patch is also a map. The second is the long tail: the Wholesale Lead Capture bug was fixed in February and still drew six-figure attack volumes in the summer, because enough sites never updated.

What happened just outside the quarter

• Bricksforge (CVE-2026-85097, unauthenticated upload) has been exploited since 7 October.
• Ninja Forms up to 3.15.3 and WPC Product Bundles up to 8.6.6: unauthenticated stored XSS disclosed on 22 September and exploited from 4 October. Patchstack describes the payload installing a plugin that hides its own administrator account.
• UpdraftCentral keys were stolen and abused on 18 and 19 October. This is not a code bug and there is no update for it: Patchstack’s advice is to delete the UpdraftCentral keys.

Did any plugin make the CISA KEV catalogue?

No. CISA added 100 entries to the KEV catalogue in Q3 2026. The WordPress ones were CVE-2026-60137 and CVE-2026-63030 on 21 July and CVE-2026-87902 on 25 September, all core. If KEV is the only feed you watch, it would not have shown you the Elementor Pro attacks, which were the biggest plugin campaign of the quarter.

The volume behind those few exploited flaws is large. Patchstack counted 11,334 new WordPress vulnerabilities in 2025, 91% of them in plugins, 9% in themes and 6 in core, and 46% had no patch when they were disclosed. In our own plugin list we found at least 20 CVEs published in Q3, among them in WooCommerce, Rank Math, TranslatePress, LiteSpeed Cache, Elementor, Essential Addons, UpdraftPlus and Customer Reviews for WooCommerce. None of them was reported exploited.

That is the real shape of WordPress risk: a large, constant stream of disclosures that mostly never turns into attacks, and a handful that turn into attacks the same afternoon. A maintenance process has to handle both.

What did the bots try on our own sites?

We look after a small fleet of client and own WordPress sites spread across our K3s cluster and two budget shared hosts. Two of them run Wordfence on our cluster: a WooCommerce shop and a staging copy of a client’s magazine site. Wordfence keeps only about 30 days of firewall data, so the numbers below cover 19 September to 20 October 2026, plus the login log from August.

The distinct-IP counts are a lower bound. The shop sits behind a CDN, and Wordfence attributed part of the traffic to two CDN node addresses instead of the visitors behind them. There is more on that in the section about what Wordfence got wrong.

The firewall caught exploits for plugins nobody installed

These are the firewall signatures that fired on the staging site. None of the targeted plugins is installed there.

Exploit scanners do not check what you run first. They spray a list, old bugs included, and count on the share of sites that never updated. Nothing in this table was a threat to a patched site. The firewall did not save us here. Being up to date did.

Two other things stand out. The staging copy has its own hostname, and the bots found it anyway. They also knew the owner’s real username: failed logins on it rose from 72 in September (from 65 IPs) to 187 in the first 20 days of October (from 157 IPs).

The login our AI agent leaked

The shop has a WordPress account that our AI agent uses to publish articles through the WordPress MCP. Its username was generated from the tool’s name, and it has the shop manager role, which can see orders and customer data. The integration only uses an application password.

WordPress showed that username to everyone. With the display name left at its default, every RSS item carried the login name in its <dc:creator> field, and the same name was the slug of a public author page. The REST users endpoint was correctly closed. The leak was the display name.

The bots noticed:

In August the traffic was the usual guessing at admin. By October the guessing had moved to the one real, privileged username the site published, spread across so many addresses that each one tried only about one and a half times. A per-IP rate limit barely notices a pattern like that. Every successful login in the log in this period belonged to the site owner’s own administrator account.

What we changed on 20 October: the account’s display name and nickname now show the shop’s name, and its author slug changed. The RSS feed no longer contains the login name, and the old author page returns 404. We do not name the account here: the bots already have it, and there is no reason to confirm it to anyone else.

The lesson goes beyond WordPress. An automation account is a user account. It gets a role, a password and a public footprint, and it needs the same review as a human admin: least privilege, no password login if it only uses an application password, and nothing in public output that names it.

What the Wordfence scanner flagged, and what it got wrong

• A “malicious” file manager. Wordfence reported fm.php as a script that “appears to have been added by a malicious actor” on both sites. It was ours: Tiny File Manager, installed by our client onboarding script with a pinned version and a generated password. That makes it a false positive on intent. It was still a public login page that nobody needed on the shop, so we deleted it on 20 October.
• A public debug.log. A 768 KB log from a single day of debugging in 2025 was readable at /wp-content/debug.log. It held only PHP notices and file paths, with no customer data, and WP_DEBUG was already off. We deleted it on 20 October.
• “Unable to accurately determine IPs”. This warning mattered more than it looks. The shop is behind the QUIC.cloud CDN, and Wordfence was reading X-Forwarded-For with no trusted proxy list. Part of the attack traffic, and all of the owner’s logins, were attributed to two CDN node addresses, and Wordfence had blocked both nodes for brute force and firewall hits. Legitimate visitors who reach the site through one of those nodes can be blocked with the attacker. The fix is to tell Wordfence which proxies to trust.
• A removed plugin. The standalone Wordfence Login Security plugin was closed on wordpress.org on 17 August 2026 at the author’s request, because its features are in the main Wordfence plugin. No security reason was given. Running both is redundant.

Were our sites ever exposed?

As of 20 October, none of the WordPress sites on our cluster runs a vulnerable version of anything exploited in Q3. Core is on 7.0.7 or 7.1.3, above every fixed release in the table, and the one site with Elementor Pro runs 4.3.2. Patched is not the same as never hit. One client site that we maintain but that is hosted on a budget shared host was infected with malware in the quarter, and we cleaned it.

How we patch, and where it falls short:

• Updates are manual and monthly. We do not switch on plugin auto-updates on client sites, because an update can break a theme or a layout silently. Nobody gets an error, the page just looks wrong. A monthly window lets someone look at the pages after the update.
• Core security releases are not left to the window. The two core fixes that mattered in Q3 were pushed as automatic updates, and that is the setting we keep.
• The gap is the same-day plugin case. Elementor Pro was attacked on release day. A monthly window alone would have left a site running Elementor Pro exposed for up to four weeks. The second track is reading advisories and patching an exploited plugin out of cycle. Q3 had one such plugin, so it is a small amount of work, but somebody has to own it.

How to patch WordPress without breaking it

1. Inventory first. List every plugin, its version and whether it is active, with wp plugin list. Inactive plugins are still code on the server: remove what you do not use.
2. Keep core security releases automatic. That is what stopped wp2shell on sites nobody was watching.
3. Watch one exploitation feed, not every disclosure. Patchstack and Wordfence both publish actively exploited flaws. Check the list against your inventory. KEV alone is not enough, because it carried no WordPress plugin in Q3.
4. Patch exploited plugins the same day, everything else in the monthly window, with a visual check of the key pages afterwards.
5. Treat automation accounts like admins. Give them the narrowest role, application passwords only, and a display name that is not the login.
6. Read the scanner output. Our “malware” was our own tool, while the quiet warnings (the public log, the CDN IP problem) were the real findings. You only learn which is which by reading it.
7. Export your firewall data monthly. Wordfence forgets after about 30 days. We now export it every month, so the Q4 issue of this series will have a full quarter.

Who does not need this?

• A brochure site with no plugins beyond the basics and core auto-updates on. For you, the Q3 risk was core, and core patched itself.
• Sites already on a managed WordPress host that patches plugins and reads advisories. Check that they really do both, then stop worrying about this list.
• Anyone planning to replace WordPress anyway. A static site has none of these problems. We moved several of our own and client sites to a static build this year. That is a project, though, not a patch, and until it ships the current site needs the same care.

Everyone else running WooCommerce, page builders or form plugins needs a monthly window and a same-day track.

Keeping WordPress patched without breaking the layout is a routine we run for clients. It runs either as fully managed web hosting on our own platform or as part of our infrastructure services on the host you already have. If nobody owns the same-day patch on your WordPress sites, book a free discovery call.