WordPress Plugin Auto Update: 3 Channels, 1 Dead End

There is a small switch on your Plugins screen labelled “Enable auto-updates”. I pulled the first fifteen results for WordPress plugin auto update this morning and every one of them is a tutorial for finding that switch. Not one headline or summary in that set mentions that the switch has three completely different meanings depending on which plugin you flip it for, or that for at least one plugin on a typical site it means nothing at all.

I found this out the boring way: by reading the update data WordPress had already collected about my own site, instead of looking at the screen that summarises it. Fifty plugins checked, sixteen updates waiting, and three different delivery mechanisms behind them — one of which cannot deliver anything.

It matters this month in particular, because the two plugins under the heaviest attack in the WordPress ecosystem right now are both on the side of that split where wordpress.org has no idea they exist.

440,000 blocked attempts, on two plugins wordpress.org has never heard of

Between them, Wordfence has blocked more than 440,000 exploit attempts against two arbitrary-file-upload flaws this summer: 250,000 against Super Forms and 190,000 against Elementor Pro. Both flaws let an unauthenticated visitor write a PHP file to the server and run it.

Both plugins are commercial. Neither is distributed through wordpress.org. Ask the wordpress.org plugin API about Super Forms and it answers with a flat 404 Plugin not found. Elementor Pro is a paid add-on shipped by Elementor against a licence, not a repository listing. So whatever your auto-update setting says, the fix for either one has to arrive through a channel WordPress core did not build and cannot inspect.

Read the Super Forms row slowly, because it is the whole argument in one line. The vendor shipped the patched build, 6.3.314, on 8 July 2026. Wordfence published the vulnerability on 9 July. Attackers started firing on 14 July — the same day Wordfence shipped a firewall rule to its paying customers. Sites running the free version of Wordfence got that same rule on 13 August, thirty days later.

So for a full month, a site with a free scanner and a stale copy of a commercial plugin had neither the patch nor the rule, while a quarter of a million requests went looking. That is not a criticism of the 30-day delay, which is a well-signposted commercial policy and buys the research that finds these things. It is a point about arithmetic: if your patch channel is slow and your rule channel is delayed, the two gaps do not average out. They stack.

The one where the timing worked

Elementor Pro is the counter-example, and it deserves saying plainly. The vulnerability was disclosed on 19 August 2026 and the vendor shipped 4.2.2 the same day. Every Wordfence tier, free included, was already covered by the firewall’s generic malicious-file-upload protection — no 30-day wait, because no bespoke rule was needed.

The scale claim needs trimming too. Elementor Pro has more than six million active installations, and 190,000 blocked attempts sounds like a rout. But exploitation needs a specific precondition: the site must have published a page containing an Elementor Pro Form widget with at least one non-required File Upload field. That is a small minority of six million sites. It is also why the CVE carries two different severity scores, which I will come back to.

The four flaws, and where each fix actually lives

Four WordPress plugin vulnerabilities landed in a five-week window. Here is the whole set as the primary sources describe them, not as the round-ups do.

The install figures for the bottom two come from the wordpress.org plugin API, which is the same source your dashboard reads. The two commercial plugins have no such listing, so their figures come from Wordfence’s disclosure posts.

Notice the pattern in the last column. The two flaws that drew 440,000 attacks are the two whose fixes wordpress.org cannot serve. Neither disclosure post for the two whose fixes it can serve reports exploitation in the wild. I would not claim the channel causes the attacks — small commercial plugins are also less audited, which is the next chart — but if you are triaging your own site, “where does this plugin’s update come from” turns out to sort the risk better than install count does.

Two things the coverage got wrong, both checkable in a minute

I went to the National Vulnerability Database for each CVE, because it is free, unauthenticated, and answers in JSON: services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-32475. Two discrepancies fell out.

The Elementor Pro severity is not settled. Wordfence publishes 9.8 Critical. The record NVD carries for the same CVE, assigned by Patchstack, is 9.0 — and the vectors differ in a way that matters: Patchstack scores it AC:H, high attack complexity, which is the numeric expression of that non-required-upload-field precondition. Articles quoting 9.8 are quoting Wordfence accurately. Two competent authorities looked at one bug and disagreed about how hard it is to reach. Worth knowing before you decide how fast to move.

One CVE is attributed to the wrong plugin. A widely syndicated write-up describes CVE-2026-19598 as an Everest Forms file-upload flaw affecting “versions before 3.0.9.5” and exposing more than 100,000 sites. NVD’s record for CVE-2026-19598 names Pods – Custom Content Types and Fields, versions up to and including 3.3.9, and describes a privilege-escalation authorisation bypass, not a file upload. The mechanism is specific and unmistakeable: the pods_admin AJAX router funnels every access check through pods_error(), which under one compatibility path writes the failure to the error log and returns false instead of terminating the request. Every guard becomes advisory.

The “100,000 sites” figure is the interesting part. Pods reports 100,000 active installs on wordpress.org; Everest Forms reports 90,000. So the count belongs to the plugin the article did not name. If you read that piece, checked your Everest Forms version, and moved on, you did the work and got no safety from it. This is the tenth time a secondary source has turned up here carrying a figure the primary source contradicts, and it is the cheapest one to catch yet — one HTTP request per CVE.

Why the small plugin is the dangerous one

Super Forms and Elementor Pro were hit by the same class of defect: a file-upload validation path that can be talked into accepting a .php file. The researcher who found the Elementor Pro one was paid $15,600. The researcher who found the Super Forms one was paid $33.

That is a 473-fold gap for the same bug class, and it is not anybody behaving badly — bounties scale with install count, which is a rational way to spend a finite research budget. But follow the incentive to its conclusion. Super Forms has 13,000 installs, roughly two-tenths of one percent of Elementor Pro’s user base, and it drew thirty-two percent more blocked attack traffic. Attackers are not sizing targets by install count. They are sizing them by how likely the flaw is to still be sitting there.

The Super Forms chain shows why that bet pays. The upload handler is a nopriv AJAX endpoint with no capability check, guarded only by a nonce — and a second nopriv endpoint, super_create_nonce, will mint a valid nonce and session cookie for any anonymous visitor who asks. Total cost of exploitation: two unauthenticated HTTP requests. A defect that cheap to fire, on a plugin nobody is paid to audit, is worth a scanner’s time even at 13,000 installs.

The All-in-One WP Migration flaw is the opposite shape and worth a sentence for contrast. It is second-order: the injected SQL sits inert until an administrator performs an archive restore, at which point it leaks the plugin’s ai1wm_secret_key and remote code execution follows. Nobody can trigger it on your behalf. It waits for you to do a routine maintenance task. Free-tier Wordfence users, incidentally, are scheduled to get that firewall rule on 15 September 2026 — five days after this post goes up.

So I read the update data on my own site

Two weeks ago I audited this install and found eight of forty-eight active plugins behind, with the oldest available fix eight days old. I re-ran it this morning. The count has doubled to sixteen. The worst-case lag is still eight days.

This time I did not stop at the Plugins screen. WordPress stores the answer in a site transient called update_plugins, and that object holds something the screen throws away: the URL each update would actually be fetched from.

Three groups, from one transient:

Reading down the rows:

• Ten from downloads.wordpress.org. These are the ones the toggle genuinely handles. The bar is days since the wordpress.org release, so it is a direct read on how late this site is: eight days at worst, two days for Wordfence itself, one day for the newest.
• Five from storage.googleapis.com. A vendor bucket. These update fine — the vendor built an updater and it works — but wordpress.org holds no record of them, so there is no public release date to be late against and no third party who can tell you a version is old.
• One with no package URL at all. seo-by-rank-math-pro reports new_version: 3.0.121 and an empty package field, with unavailability_reason: 'update_free'. Core has been told a newer version exists and has been told it cannot have it.

That last row is the finding I did not expect. It is not a bug and it is not a mystery — a licence-gated updater is behaving exactly as designed when it withholds the download. But the consequence is that the Plugins screen shows an update notice that no amount of clicking will ever clear, and nothing on that screen distinguishes it from the ten rows above it that will install in four seconds. If a security release ever arrives through that path, the site will be told about it and will not be able to take it.

I have written before about a core security release that never installed on this same site while every setting said it would. This is the plugin-layer version of that failure, and it has the same signature: the dashboard is not lying to you, it is just answering a different question than the one you asked.

What to actually do about it

Nothing here requires new tooling. It requires asking a different question.

1. Sort your plugins by update channel, not by name. Anything you paid for is probably off-repo, which means its fix depends on a live licence and a vendor server. Those are the rows to check by hand. One WP-CLI line prints the whole picture: wp eval 'foreach(get_site_transient("update_plugins")->response as $f=>$o){echo $f." ".($o->package ? parse_url($o->package,PHP_URL_HOST) : "NO PACKAGE")."\n";}'
2. Treat an update notice that never clears as an incident, not a nuisance. An empty package field means an expired or downgraded licence. It is a five-minute billing fix and it silently disables security updates for that plugin until you make it.
3. Check the CVE at NVD before you decide how urgent it is. One request, no key. Severity scores disagree between assigners and version ranges get transcribed wrong; the vector string tells you whether a flaw needs a precondition you may not even have.
4. Know which firewall tier you are on and what it costs you in days. If you are on a free scanner, assume rules for bespoke vulnerabilities arrive roughly a month after the paying tier, and that the patch is therefore your primary defence rather than your backup.
5. Look at your forms specifically. Three of the four flaws above are in form or import plugins, and two of them turn on file-upload fields. If you have a published form with an optional file upload, that is the highest-value thing on your site to review this week.

If you run an AI chatbot on WordPress, the same question applies to it: our own add-ons are in that middle group, served from a vendor bucket, which is exactly why the documentation covers version checks and why the add-ons page lists current versions rather than leaving you to guess. The scanning we did on where API keys actually live on a WordPress install came out of the same habit of reading the stored data instead of the summary screen. And if you would rather not audit a chatbot integration yourself, MxChat Pro exists partly so that there is one fewer moving part in this pile.

Frequently asked questions

Does enabling auto-updates protect me from these four vulnerabilities? For All-in-One WP Migration and Pods, yes — both fixes are on wordpress.org and core will fetch them. For Super Forms and Elementor Pro, only if the vendor’s own updater is installed and the licence is active. The toggle by itself does nothing for a plugin core cannot locate.

My Plugins screen shows an update that will not install. Is my site compromised? Almost certainly not. The usual cause is a licence that has lapsed or dropped to a free tier, so the vendor reports the new version but withholds the download. Check the plugin’s own licence page first.

Is Elementor Pro’s flaw a 9.8 or a 9.0? Both figures are real. Wordfence assigns 9.8; the record in NVD, from Patchstack, assigns 9.0 with high attack complexity, reflecting that exploitation needs a published Pro form with a non-required file-upload field. Check whether you have such a form; that single fact moves your risk more than the score does.

I use Everest Forms, not Pods. Am I affected by CVE-2026-19598? Not according to NVD, which names Pods for that CVE. Some coverage attributes it to Everest Forms. Look the CVE up yourself rather than trusting either me or the article.

How far behind is normal? On this site, eight days at worst across ten wordpress.org-hosted plugins, with a median of four. When I checked Patchstack’s 2026 security research in August, its median time from public disclosure to mass exploitation was five hours, so “a few days behind” is not a comfortable place to be — it is just a common one.

The short version

The auto-update toggle is not one feature. It is a routing decision, and the route matters more than the switch. On the site I audited this morning, ten of sixteen pending updates come from wordpress.org and will install themselves, five come from a vendor bucket and will install themselves without anyone outside the vendor knowing what version is current, and one cannot install at all and will keep saying it can.

The 440,000 attacks this summer landed on the two plugins in the second category. That is where to spend your attention: not on whether the switch is on, but on whether anything is on the other end of it.