Top/Articles/WordPress plugins shipped malware via official updates: CVE-2026-11976
wordpress-plugin-update-supply-chain-cover-en

WordPress plugins shipped malware via official updates: CVE-2026-11976

MonsterInsights Pro shipped malware after its update bucket was hijacked. The version it rolled back to was poisoned too. Three CVEs, 9.8+. Paid versions only.

NewsPublished Aug. 7, 2026 Updated today
Table of contents
Key takeaways

MonsterInsights Pro shipped malware after its update bucket was hijacked. The version it rolled back to was poisoned too. Three CVEs, 9.8+. Paid versions only.

On August 7, 2026, three vulnerabilities involving WordPress plugins were assigned CVE numbers at once. What the three have in common is not the nature of the flaw. It is that the delivery channel for the plugins themselves was hijacked, so sites that applied a legitimate "update" ended up with malware.

At the center is MonsterInsights Pro (CVE-2026-11976, severity 10.0, the maximum). It is the paid edition of a staple plugin that brings web analytics into the WordPress admin screen. The free edition alone runs on 2 million sites.

Here is what happened. The storage location on Amazon's cloud where the update files were kept (an S3 bucket) was taken over, and a malicious file named class-system-check.php was slipped into version 10.2.2 while it was being distributed. The developer noticed something was wrong and rolled back to the previous release, 10.2.0. But the same file was already sitting in 10.2.0 as well.

According to the record kept by WPScan, the organization that assigned the number, three variants were observed over the course of a single day on June 11, and all three used the same encryption key. In other words, one attacker held write access to that storage location and kept reworking its contents throughout the day. The safe version is 11.0.0 or later.

The other two cases follow the same shape. Three paid plugins from Supsystic (CVE-2026-17032, severity 9.8) were shipped with malicious code after the developer's own update server was hijacked. And Premium SEO (CVE-2026-14812, severity 10.0) was a plugin built for takeover from the very start.

For scale: the number of WordPress-related vulnerabilities added to the U.S. National Vulnerability Database (NVD) that same day, counting plugins and design templates together, tops 150. Nearly all of them are ordinary vulnerabilities — a hole in how the program was written — and applying the fixed version ends the matter. The three covered here are a different species from any of those, because the problem is not how the code was written but how it was delivered.

Who is affected, and what to do

Here are all three side by side so you can check whether your site is affected. In all three cases, only the paid editions are affected. The free editions hosted in the official WordPress directory (WordPress.org) are not covered by any of these. The severity figures come from WPScan, which assigned the numbers; as of August 7, NVD had not published its own scores.

CVEPluginWhat it doesTainted versionsSafe versionLogin neededSeverity
CVE-2026
-11976
MonsterInsights
Pro (paid)
Analytics in the
admin dashboard
10.2.0
10.2.2
11.0.0 or laterNo10.0
CVE-2026
-17032
Easy Google Maps
Pro (paid)
Embedded maps1.6.91.7.0 or laterNo9.8
CVE-2026
-17032
Photo Gallery
by Supsystic Pro
Photo galleries2.10.92.11.1 or laterNo9.8
CVE-2026
-17032
Data Tables
Generator Pro
Building tables1.9.201.10.1 or laterNo9.8
CVE-2026
-14812
Premium SEOSearch optimization
(supposedly)
6.x / 30 / 36
37 / 38
None
(delete it)
No10.0

As you can see, all five require no login. The attacker needs neither a username nor a password, because the plugin arrives with the attacker's entryway already built into it.

Who is behind this, what they do, and what you stand to lose

The people who choose this method are attackers who have given up on hitting sites one at a time and instead hit the distributor once. Rather than combing individual sites for holes, it pays far better to seize a channel that reaches every site running the plugin in a single stroke. In the MonsterInsights case, the target was not a website at all but a single storage bucket of update files that the developer kept on Amazon's cloud.

And then what? They embed machinery in the distributed package that quietly creates administrator accounts. An administrator account that never appears in the interface gets set up, and its username and password are sent outside. The mechanics differ from case to case. The file mixed into MonsterInsights built an entryway that lets someone through authentication simply by appending a particular string to a URL. The code distributed in June through OptinMonster and its siblings was written to wait quietly for the site's administrator to log in and, the moment the dashboard opened, borrow those privileges to create the account. The shape of the entrance differs; where it leads does not.

The destination is shared too: tidio.cc — an unrelated domain deliberately kept one character away from tidio.com, the widely used chat tool. Scanning traffic logs, it looks like a familiar name.

What you lose is the site itself. Once someone holds an administrator account, they can rewrite your posts, swap out your payment destination, or serve different malware to your visitors. If you sell online, order records and shipping addresses are sitting there ready to be carried off; if you run a membership site, so is your member list. The heaviest part of this case is that the break-in was not the result of visiting a shady site, but the result of clicking the update button in the dashboard — an entirely correct thing to do. The same pattern played out when axios, a staple JavaScript component, was hijacked, and when four open-source projects fell in a 10-day chain reaction that started with the scanner Trivy.

With MonsterInsights, even the rollback target was tainted

CVE-2026-11976: the update file store itself was taken over

Severity 10.0. On CVSS, a scale that tops out at 10, there is nothing higher. Written in shorthand, it is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: exploitable over the network, with no tricky preconditions, no privileges and no action from the user, and with damage that spreads beyond the site itself (S:C).

What was taken over was monster-insights.s3.amazonaws.com, the location on Amazon's cloud storage where MonsterInsights Pro's update files lived. The attacker obtained write access there and added class-system-check.php to the distributed package. By name alone it reads like a "system check" component, and it does not look out of place inside a plugin.

The trouble is what came next. The developer found the problem in 10.2.2, which was being distributed at the time, and rolled back to the previous 10.2.0. As incident response goes, that is the textbook call. But 10.2.0 already contained the same malicious file. The attacker had poisoned the version that would become the rollback target in advance.

WPScan's analysis rates the build that shipped in 10.2.0 as the most dangerous. It carried three capabilities: hijacking the update mechanism itself, planting an administrator account that will not go away, and bypassing authentication with nothing more than a particular string appended to the URL. As long as the first of those is active, you can update to what you believe is a clean version and still receive whatever the attacker has prepared.

Over the course of June 11, three variants were observed. All three used the same encryption key (AES-256-GCM), which is the basis for concluding that a single actor — one person or one group, not several — spent the day reworking the payload. The NVD entry states explicitly that the attacker still held write access to the storage location at the time of the report.

The leaked AWS access key is AKIA2QECJAQPPMAUL6XT. The safe version is 11.0.0 or later; the current free edition is 11.1.2 (updated July 29). The report came from Mike Gozdiskowski, the same researcher behind the Supsystic report discussed below.

This connects to the OptinMonster incident back in June

Worth pausing here on where MonsterInsights sits. The company's own about page names Syed Balkhi as its founder and lists "sister brands" including OptinMonster, WPForms, All in One SEO, SeedProd and Duplicator. Its careers page points to Awesome Motive. Think of it as a single family of brands, and one of the largest in the WordPress world.

The numbers look like this. Counting free-edition installs alone: WPForms 5 million sites, All in One SEO 3 million, MonsterInsights 2 million, OptinMonster 1 million. Those four together come to 11 million sites. That is the reach when one distribution channel is broken open.

This family of brands was already in the news over this in June 2026. According to research by the Dutch security firm Sansec and reporting from BleepingComputer, files served from the delivery network (CDN) were swapped out for three products: OptinMonster, TrustPulse and PushEngage. A CDN is a relay network that delivers images and programs quickly to users around the world. The attacker got into the server running Awesome Motive's marketing site through a known hole in a different plugin, UpdraftPlus, and made off with the CDN keys stored there. The way in was not the plugin itself but the promotional website.

The hole used as that entrance may well be on your own site too. UpdraftPlus is a backup plugin, and about 3 million sites run it. The flaw is CVE-2026-10795 (severity 8.1), affecting 1.26.4 and earlier, fixed in 1.26.5; the current release is 1.26.6. It lets an attacker slip past authentication without logging in, it was published on June 10, and two days later it was used in this very attack. As of August 6 it does not appear in the U.S. CISA catalog of vulnerabilities known to be exploited, but a documented record of real-world use arguably weighs more than presence on the list. Even if none of the three cases here applies to you, this one is worth checking.

The code planted back then also waited for an administrator to log in, created a hidden administrator, and sent the credentials to tidio.cc. The backdoor it installed was built so that it appeared neither in the plugin list nor in update checks, and Sansec identified two aliases it used: "Content Delivery Helper" and "Database Optimizer."

What stands out is how briefly it was live. By Sansec's account, the malicious code was served for OptinMonster and TrustPulse for 25 minutes, from 22:17 to 22:42 UTC on a Friday. Only PushEngage ran longer, until 19:02 UTC the following day. Twenty-five minutes of a swapped externally loaded file is enough to reach something on the order of a million sites. You can be caught up in it without having touched a single line of your own site's code — that is the essence of this technique.

In the MonsterInsights Pro case that has now received a CVE, the exfiltration domain matches and the timing overlaps almost exactly, June 11 to 12. Treating it as part of the same campaign is the natural read. There is a difference, though. What was reported in June was the swapping of JavaScript served from a CDN; what has now been assigned a CVE is PHP files in the plugin itself being mixed into the legitimate update distribution. This one reaches deeper.

The developer has never disclosed that the S3 bucket was taken over

The fixed version, 11.0.0, went out on June 17. Yet what the official changelog records under 11.0.0 is a single line: various bug fixes and updates. Nothing about malware in the distributed package, nothing about the cause. Neither the blog nor the announcements carry any report of the incident.

What the official account did post on June 12 was about something else.

What that notice refers to is fake update emails riding on the confusion. Messages went around claiming to be "MonsterInsights 10.3.0 Critical Security Update," but there is no version 10.3.0 (10.2.2 was followed by 11.0.0). The vulnerability number quoted in them did not exist either, and the link led to a lookalike site whose domain name had one extra "i" in it.

The reaction from people on the receiving end is on the record too.

The official site wasn't responding, and the only thing arriving was a plausible-looking update email — that was the view from the user's side. A warning about phishing did go out, but an explanation that the distributed package itself had been tainted never came, not then and not after 11.0.0 shipped.

Supsystic's paid plugins were made to fetch fake updates on their own

CVE-2026-17032: one passphrase and commands go through

Severity 9.8. The affected products are three paid plugins sold by a developer called Supsystic: Easy Google Maps Pro (1.6.9) for maps, Photo Gallery by Supsystic Pro (2.10.9) for photos, and Data Tables Generator Pro (1.9.20) for tables. Here too the way in was the developer's update server, which was hijacked and then handed out builds with malicious code baked in.

Drawing on WPScan's record, the planted capabilities break down as follows.

First, command execution via a passphrase. Attach one fixed line, X-Forwarded-Validation: supsystic-cdn-82a7, to a web request and any command you like runs on the server. No login required. Second, authentication bypass: present the right passphrase and you are in as an administrator with no password. Third, automatic creation of administrator accounts, where the username and password are derived mechanically from the site's own settings, so an attacker can work them out ahead of time. On top of that, the site's URL, the server's IP address and assorted version numbers were being sent back to the attacker.

The nastiest piece is the one built for staying put. The plugin's automatic update destination was pointed at a distribution server the attacker controlled. You clean the site up, and the next automatic update brings the same thing right back. That is the same goal as the "hijack the update mechanism" function found in MonsterInsights 10.2.0.

The fixed versions are 1.7.0 / 2.11.1 / 1.10.1. This case was registered with WPScan on July 24, and the CVE number was assigned on August 7. The free editions (Easy Google Maps 20,000 sites, Photo Gallery 20,000 sites, Data Tables Generator 10,000 sites) are not affected.

Here too, there was no disclosure. Neither Supsystic's own site nor the official WordPress support forums carry any explanation of the incident. All that remains is a single line in the changelogs of the three free plugins. Between July 30 and 31, Easy Google Maps 1.13.0, Photo Gallery 1.17.1 and Data Tables Generator 1.13.1 were updated one after another, each carrying the same wording.

Added further security hardening and unofficial version detected

"Unofficial version detected" reads as though code was added to recognize the tainted builds. But nothing says what happened, who is affected, or how to check. A user is not going to get from that one line to this incident.

"Premium SEO" was built to take over sites from day one

CVE-2026-14812: there is no fixed version

Severity 10.0. This one is a different animal from the other two, though. It is not that a vulnerability was found in the plugin; the plugin itself was built to take over sites. The WPScan record by Erwan LR classifies the product bluntly as a "malicious plugin."

"Premium SEO" (credited to Web SEO Services) does not exist in the official WordPress directory. Where it was being distributed from is not known — WPScan's record doesn't say either. The one established fact is that it arrived without passing through the official directory. The affected builds are 6.x / 30 / 36 / 37 / 38. Every version can create hidden administrators and inject content, and from the 6.x line onward it adds command execution on the server, probing of the internal network, and dumping of server information.

A word of caution about the name. There is a completely separate, legitimate plugin called "Premium SEO Pack". WPScan goes out of its way to note this. The names merely resemble each other; that one has nothing to do with this incident. To avoid deleting the wrong thing, check whether the folder name is Premium-SEO.

The indicators are clear. The file is wp-content/plugins/Premium-SEO/seo-automation.php. The administrator it creates has a username beginning with resource_desk_ and the email address wppremiumseoplugin@gmail.com. It communicates with public.imagehosting.space and public1.imagehosting.space. In the database it writes settings such as head_scripts_seo, copyright_footer_links and seo_automation_owner_id.

There is no fixed version, because there is no one to fix it. The response is deletion, removal of any administrator accounts it planted, and a check for spam landing pages it created on its own plus scripts injected into the header and footer. All three cases share this: updating is not where the job ends.

Why paid editions keep being the target

First, a sense of how wide this reaches. In W3Techs' survey, among websites written in Japanese whose underlying system can be identified, 82.8% run WordPress (as of August 6, 2026). Second place is Shopify at 2.9% — a gap of nearly 30 times. Building a Japanese-language website is, in practice, close to synonymous with using WordPress.

It is no accident that all three cases involved paid editions. WordPress plugins receive updates by two different routes.

One is through the official directory (WordPress.org). Free editions live there and their updates come from there. The code is exposed to community eyes, and WordPress runs the distribution servers. The other is through an update server the developer runs themselves. Paid editions cannot be hosted in the official directory, so each company stores its own files, checks its own licenses and does its own distribution.

The second route means thousands of separate distribution setups, each standing on its own, each maintained to whatever standard that company happens to keep. How well they are defended varies from vendor to vendor. What was breached in these three cases was one storage bucket on Amazon's cloud, one update server, and one set of keys left lying around on a marketing site. However carefully the plugin's own code is written, none of it matters if the pipe that delivers it is broken open.

From the user's side, the difference is almost invisible. The dashboard shows the same "Update" button, and free and paid plugins are updated from the same screen with the same click. Nothing on that screen tells you whether the click reaches the official directory or the developer's own server. That indistinguishability is what makes this case unsettling.

WordPress core does not check whether the update file it received is genuine

This is the fact sitting at the bottom of the whole story. WordPress does not cryptographically verify that a downloaded plugin file is authentic. That holds whether the file came from the official directory or from a developer's own server — no distinction is made.

The machinery was built once. WordPress 5.2 (May 2019) introduced the ability to attach a cryptographic signature to a release and verify it. A cryptographic signature is a way of proving mathematically that a file has not been altered since it left the publisher's hands. Even then, though, Paragon Initiative, which worked on the feature, wrote that "themes and plugins are still unsigned".

And since then? The current WordPress source code spells out the list of keys used for verification like this.

if ( time() < 1617235200 ) {
  // WordPress.org Key #1 - This key is only valid before April 1st, 2021.
  $trusted_keys[] = 'fRPyrxb/MvVLbdsYi+OOEv4xc+Eqpsj+kkAS6gNOkI0=';
}

// TODO: Add key #2 with longer expiration.

The number 1617235200 points to April 1, 2021. The moment that date passed, the list of trusted keys became empty. And that last line — the note to add key #2 with a longer expiration — is a piece of unfinished business still sitting there five years later.

In June 2024, WordPress switched the verification off altogether. The record of that change gives the reason: disable it "at least until signing is fully implemented on WordPress.org." And in fact, the function that downloads a release today has the "verify the signature?" argument hard-wired to false.

What can be checked is limited. The official directory publishes a per-plugin file list with checksums — values computed from a file's contents, like a fingerprint. But the only thing that goes and reads them is WP-CLI, the command-line version; WordPress core's own update routine never consults them. And for self-distributed paid editions, no such list exists in the first place. The only thing actually verified is that the connection is encrypted (HTTPS). If the party on the other end of that connection has been taken over, encryption protects nothing. Which is exactly what happened with MonsterInsights.

A plugin can rewrite where its own updates are fetched from

There is a second reason the "hijack the update mechanism" capability seen in two of these cases works at all.

For a paid edition to deliver updates from its own server, it has to tell WordPress "the new version of this plugin is over here." The hook for doing so exists as an officially documented extension point. A plugin inserts its own row into the list of available updates and is free to write whatever download URL it likes. This is not a bug; it is the legitimate design that makes the paid-plugin business possible.

Turn that around and code that has once made it onto a site gets to decide where its future updates come from. Supsystic's "automatic update destination pointed at the attacker" and MonsterInsights 10.2.0's "hijack the update mechanism" capability both ride on this design. That is the reason a site you thought you cleaned gets reinfected at the next automatic update. Deleting a plugin and reinstalling it, rather than just updating, is worth doing precisely because it cuts that path.

The same thing has happened three times in two months

Is this a freak accident? No. Hijacked distribution channels for paid plugins have been happening back to back.

In June 2026, backdoors were planted in three paid plugins from a developer called ShapedPlugin. The tainted builds were Smart Post Show Pro 4.0.1, Product Slider for WooCommerce Pro 3.5.2 and Real Testimonials Pro 3.2.4, fixed in 4.0.2, 3.5.3 and 3.2.5 respectively. That is CVE-2026-10735, severity 9.8. Distribution ran through the company's license management server, and the free editions in the official directory were untouched. According to reporting on the case, what was carried off included database credentials, administrator accounts, mail-sending credentials, and online store order data.

There is one more line in that record. WPScan notes that "after reporting, the developer became unreachable." Distributing your own product means also carrying, yourself, the duty to speak up when something goes wrong. When that duty goes unmet, users have no way of finding out.

Go back further and you reach July 2025, when malware was found in versions 2.9.11.1 and 2.9.12 of Gravity Forms as served from the vendor's own site. In that case, though, the developer stated plainly that anyone who installed via automatic updates was unaffected; only manual downloads and Composer installs were tainted. We have covered Gravity Forms vulnerabilities here more than once. July 2025, June 2026, and now this. What is being targeted is not one particular company but the WordPress arrangement itself, in which every vendor distributes its own paid edition.

One more thing: a plugin installed from outside the official directory shows no update notice in the dashboard even after a danger comes to light. The same reason kept updates from reaching users in three of the 24 flaws disclosed on August 5. You can also check whether the libraries and plugins you use have known problems with a free tool that matches them just by pasting in your dependencies.

Checking whether your own site is infected

For all three cases, updating is not the end of it. If someone already got in, they left things behind. Here is what to look at, in order.

1. Open the user list. Go to "Users" in the dashboard and check whether any administrator is there that you don't recognize. Start with the ones whose names are known. For Premium SEO, look for a username starting with resource_desk_ or the email address wppremiumseoplugin@gmail.com. For the June Awesome Motive incident, Patchstack's analysis reports two kinds: a fixed username developer_api1 (with the email customer1usx@gmail.com), and usernames made of dev_ followed by random characters. Even if nothing matches those, treat any unfamiliar administrator created on or after June 11 as suspect.

2. Look for the files. On the server, check whether class-system-check.php (MonsterInsights Pro) or Premium-SEO/seo-automation.php (Premium SEO) is present.

3. Check outbound destinations. Search your server's traffic logs for tidio.cc and imagehosting.space. tidio.cc has nothing to do with tidio.com. It is easy to miss on sites that genuinely use the Tidio chat tool, so read all the way to the end of the name.

4. Suspect an invisible backdoor. The backdoor installed in the June incident was built not to appear in the plugin list. The names were "Content Delivery Helper" and "Database Optimizer." Because they don't show up in the list, you need to look directly at wp-content/plugins/ on the server as files. The quickest route is to compare the number of plugins shown in the dashboard against the number of folders sitting there.

5. Rotate your passwords. Assume credentials were sent outside, and replace administrator passwords, database connection details and API keys for any external services.

Is this actually being exploited?

✓ Confirmed facts

  • That a malicious file was mixed into the MonsterInsights Pro distribution, and that the rollback target 10.2.0 was tainted as well (WPScan)
  • That three variants were observed on June 11 and shared the same encryption key (NVD)
  • That CDN files for OptinMonster, TrustPulse and PushEngage were swapped out, and that Awesome Motive has acknowledged it (Sansec, BleepingComputer)
  • That three paid Supsystic plugins were distributed with malicious code by way of the update server (WPScan)
  • That as of August 6, none of the three appear in the U.S. government's CISA catalog of vulnerabilities known to be exploited (1,661 entries in total)

? Still unknown

  • ?How many people use MonsterInsights Pro — sales figures for the paid edition have not been published. The 2 million sites running the free edition are not affected
  • ?How many sites actually downloaded a tainted version — neither the developer nor the researchers have given a number
  • ?Who the attacker is — no investigation so far has attributed this to any particular group
  • ?Whether the MonsterInsights Pro case and the Supsystic case are the work of the same attacker — the reporter is the same researcher, but no published evidence links the two
  • ?When and how the attacker first got into the S3 bucket — WPScan doesn't say. Assuming it was via UpdraftPlus, as in the CDN case, is a natural guess, but there is nothing to back it up
  • ?Where Premium SEO was being distributed from — it is certainly not in the official directory, but no primary source points to its distribution channel

One more thing belongs in the record. Neither MonsterInsights nor Supsystic has told its users that a breach took place. For the former, the changelog for the fixed 11.0.0 is one line about various bug fixes and updates; for the latter, all there is is "unofficial version detected" in the free editions' changelogs. For the June CDN swap (OptinMonster and the others), each brand did put out an official statement — the responses have diverged.

To sum up, it is settled that malicious code really was distributed, and what remains unpublished is the scale of the damage beyond that point. Because this kind of attack sits dormant until an administrator logs in, an infected site looks no different from the outside. The absence of numbers does not mean there were no victims.

What to do

Start by listing the plugins you paid for. Everything affected here is a paid edition. If you run MonsterInsights Pro, move to 11.0.0 or later; for the three paid Supsystic plugins, move to 1.7.0 / 2.11.1 / 1.10.1 or later. Premium SEO should be deleted.

Next, don't stop at updating. Work through the five items in the previous section — the user list, the files, outbound destinations, hidden plugins, and rotating passwords. All three of these are the kind of attack that leaves traces once someone is inside.

Then, if you can think of a plugin you installed without going through the official directory, work out where it came from. If you bought it directly from a developer, that developer is someone you are trusting — including on whether they are prepared to disclose a situation like this one. Anything whose origin you can't recall is safer deleted.

If you can run commands on your server, you can mechanically confirm that the files of plugins installed from the official directory have not been altered. WP-CLI, the command-line tool for WordPress, has a command called wp plugin verify-checksums --all that compares the file list published officially against the files you actually have. It does not work for paid editions, though, because there is no published list to compare against. Which is another way of saying that these three cases sat squarely in that blind spot.

If you change one thing about how you operate, make it this: put an inventory of plugins installed from outside the official directory on a regular schedule. Knowing how many you have lets you decide in minutes whether news like this applies to you. Don't neglect updates to WordPress core either — two vulnerabilities allowing takeover without login landed in core in July, and those are on the U.S. government's list of flaws under active attack.

Summary

On August 7, 2026, three WordPress plugin cases received CVE numbers. In all three, nothing was exploited through a hole in the code; the delivery channel was hijacked.

MonsterInsights Pro (CVE-2026-11976, severity 10.0) lost control of the storage bucket on Amazon's cloud that held its update files. A malicious file was mixed into 10.2.2 while it was being distributed, and the same file turned out to be in 10.2.0, the version rolled back to in response. As of the report, the attacker still retained write access. The safe version is 11.0.0 or later. For the three paid Supsystic plugins (CVE-2026-17032, 9.8), the update server was hijacked and even the automatic update destination was pointed at the attacker. Premium SEO (CVE-2026-14812, 10.0) was a plugin built for takeover in the first place, distributed without passing through the official directory. There is no fixed version.

Everything affected is a paid edition; the free editions in the official directory are not included. Paid editions get targeted because each vendor carries the burden of distributing updates itself. The "Update" button in the dashboard looks the same either way, but the screen never tells you whose hands the other end is in.

One layer deeper sits the fact that WordPress does not verify the authenticity of the update files it receives. The machinery for checking signatures was built in 2019, but the key's validity expired on April 1, 2021 and was never renewed, and the source code still carries a note to add key #2. In June 2024 the verification itself was disabled. All that is actually confirmed is that the connection is encrypted, and that counts for nothing if the party on the other end has been taken over.

Cases of the same shape keep coming. Gravity Forms in July 2025; three paid ShapedPlugin products in June 2026 (CVE-2026-10735). What is in question is not any single company's lapse but the arrangement itself, in which every vendor distributes its own paid edition. And in these three cases, neither MonsterInsights nor Supsystic has told its users that a breach took place.

There are so far no reports of actual exploitation and no published victim counts. But this kind of attack stays still until an administrator logs in, and an infected site looks unchanged. Applying the update and then checking for traces is what a real response looks like.

Frequently asked questions

I use the free version of MonsterInsights. Am I affected?

No. What was tainted was the distribution of the paid edition (MonsterInsights Pro); the free edition in the official WordPress directory is delivered through a different route. That said, OptinMonster and others in the same family of brands were caught up in the June incident where CDN files were swapped. If you use any plugin from that family, WPForms and All in One SEO included, it is worth at least checking for hidden administrator accounts.

Would turning off automatic updates keep me safe?

In this particular case it might have spared you, but it isn't advisable. Most plugin vulnerabilities are ones that updating would have prevented, and switching updates off is far more dangerous. Handle cases like this one by checking for traces after updating, not by refusing to update.

Severity 10.0 — is it really that bad?

In substance, yes, it deserves a perfect score. No login and no password are needed, and if it lands, administrative control of the site goes straight to the attacker. But that number describes what happens if you actually downloaded one of the affected versions. Only specific versions of the paid editions are affected, so check the table first to see whether that includes you.

If this happened in June, why did the CVE numbers appear only now?

Because a researcher's report and the assignment of a number are separate processes. The MonsterInsights case was registered with WPScan on June 11 and the Supsystic case on July 24, and the CVE numbers were issued together on August 6 and 7. The events aren't new; the trackable numbers just arrived now.

What is tidio.cc? I use Tidio.

It is a domain set up by the attacker, unrelated to the Tidio chat tool (tidio.com). Keeping it one character away from a familiar name appears designed to stop anyone from feeling something is off while glancing at traffic logs. The more legitimately you use Tidio, the easier it is to miss, so check whether the ending is .cc or .com.

If I upgrade to a safe version, is that the end of it?

It isn't. Remember that 10.2.0, the version MonsterInsights rolled back to when it spotted trouble, was already tainted. With this kind of attack, the version the distributor believed was clean is not necessarily clean. On top of that, if an administrator account was created while the tainted build was running, updating leaves that account in place. Raise the version number, and then also work through the five steps in "checking whether your own site is infected" above.

Does WordPress really not check whether an update file is genuine?

It does not. The machinery for verifying cryptographic signatures was built in WordPress 5.2 back in 2019, but plugins and themes were left out from the start. On top of that, the key used for verification expired on April 1, 2021, and in June 2024 the verification routine itself was disabled. For plugins in the official directory a file list is published, and you can compare against it with WP-CLI's wp plugin verify-checksums — but WordPress core's update routine never looks there.

I updated, but the same thing keeps coming back

The Supsystic builds and the MonsterInsights 10.2.0 build both included a function that points update fetching at the attacker. In that state, you can update to what you believe is a clean version and still receive whatever the attacker prepared. Delete the plugin completely, then download the latest version again from the developer's own customer dashboard.

Sources

avatar-m-1

Makoto Horikawa

Backend Engineer / AWS / Django