Your communications director forwards you a news story her board chair sent over, asking whether the association website is affected. You open wp-admin, scan the plugins page, and every row reads the same thing: up to date. Nothing is flagged. Nothing is pending. You write back that you are fine.
You may not be. That answer may be wrong, and the dashboard is the reason. What happened this week is worth understanding on its own. What it exposes about how WordPress reports plugin status is the part that affects every managed site in this sector, including yours.
What Happened on July 28
A malicious version of Advanced Responsive Video Embedder, a video embed plugin with roughly 20,000 active installations, was published to WordPress.org. Version 10.8.7 contained a backdoor. It is tracked as CVE-2026-18072 and carries a CVSS score of 9.8, which is close to the top of the scale. Wordfence reports that its PRISM detection system flagged the code within two hours of publication, and the WordPress.org plugin team closed the plugin for downloads the same day.
The mechanism is worth understanding, because it explains the urgency. The inserted code lives in a file called php/fn-update-check.php. It accepts an attacker-supplied value through a URL parameter, a form field, or a cookie, then compares it against a SHA-256 token hardcoded into the plugin. If the value matches, the code locates an administrator account, deliberately skipping usernames with certain prefixes, creates a persistent logged-in session for that account, and redirects the attacker into the dashboard. It then reports the site URL and the chosen administrator username to an external server. One unauthenticated request, and someone else is an administrator on your website.
This was not a coding error. Reporting describes it as a deliberate insertion, most likely following the takeover of a developer account. That distinction matters. A vulnerability is a mistake someone made in code you chose to trust. A backdoor is a person who took the trust you had already extended and used it. Your review process caught neither, because there was nothing to catch: the plugin came from the official repository, through the official update channel, signed off by the same maintainer as every prior release.
Wordfence pushed a firewall rule to paid licences on July 28. The company reports that free tier coverage arrives on August 27. If your association runs the free version and assumes the firewall has you covered, that is a month of exposure you did not know you had.
The Part That Should Worry You More
Here is the structural problem, and it is the reason this post exists. When WordPress.org closes a plugin, the sites running that plugin are not told.
Patchstack has documented this clearly. WordPress core displays a closed plugin exactly the way it displays an up-to-date one. The logic is almost reasonable: the dashboard reports whether a newer version is available, and for a plugin that has been pulled from the repository, there is no newer version. So the row reads clean. There is no warning in the Site Health screen either. The plugin keeps running, keeps loading on every page request, and keeps doing whatever it was doing.
Two sentences are worth writing on a whiteboard. Removal from the repository is not removal from your site. And because no notice appears, the absence of an update prompt is not evidence of safety. It is evidence of nothing at all.
This is not a rare edge case. During a repository cleanup in October 2024, close to a thousand plugins were closed at once. Most closures are temporary and administrative rather than security-driven, which is precisely why nobody built an alarm for them. But the sites running those plugins had no way to tell the difference between a plugin pulled for a trademark dispute and a plugin pulled because it had been backdoored.
This Is the Second WordPress Incident in Two Weeks
On July 17, WordPress patched two vulnerabilities that chain into pre-authentication remote code execution, CVE-2026-60137 and CVE-2026-63030, in releases 6.9.5 and 7.0.2. Researchers named the chain wp2shell, and exploitation in the wild was confirmed within days. We covered the exploit and the cleanup that follows a patch in two earlier posts.
The pattern is the story, not either incident. Anyone who was told a fortnight ago that this sort of thing is rare has now watched it happen twice, through two entirely different doors. wp2shell was a flaw in code the WordPress project wrote. This week was a backdoor in code a third party wrote and the repository distributed. Patching addresses the first category. Nothing in your update workflow addresses the second.
How an Association Actually Finds Out
There are only three ways to learn that a plugin on your site has been pulled, and not one of them happens on its own.
- Check the repository page directly. Someone opens the WordPress.org page for each installed plugin and checks whether it still resolves. A closed plugin shows a notice there. This is the only method that requires no subscription and no budget, and it is tedious in exact proportion to how many plugins you run.
- Subscribe to advisory feeds. Wordfence Intelligence, Patchstack, and the Drupal security advisory feed all publish continuously. Reading them is free. Reading them consistently, on a week when three other things are on fire, is the hard part.
- Assign it to somebody by name. Not a plugin, not a dashboard widget, and not a checkbox in a hosting plan. A person who reads the feeds, maps what they find against an inventory of what your site actually runs, and tells you when the two intersect.
The uncomfortable version of that list: if the answer to who does this at your organization is nobody, then your detection method for a backdoored plugin is a news story reaching your board chair before it reaches you.
What to Do on the Day a Plugin Goes Dark
If you were running Advanced Responsive Video Embedder 10.8.7, the response is not the same as patching, and the sequence matters.
- Treat the site as compromised rather than vulnerable. A site that ran the backdoored version should be assumed to have been accessed, not merely to have been reachable. Those two situations call for very different work.
- Remove the plugin entirely. Deactivating leaves the code on disk. Delete it.
- Rotate the authentication keys and salts in wp-config.php. This invalidates every existing session, including any the attacker established. It is the step most often skipped, and skipping it means an intruder who logged in last week is still logged in today.
- Audit every administrator account. Look for accounts you did not create, and for existing accounts whose role was quietly elevated. Check the date each account was registered against your own records.
- Look for the second payload. An attacker who gets administrator access rarely stops there. Scheduled tasks, must-use plugins, modified theme files, and injected database rows all outlive the removal of the original entry point. Finding the front door does not mean you found everything behind it.
Do all of this without waiting for a signal. Nobody is going to prompt you. There will be no red badge in the dashboard, no email from WordPress, and no update waiting to be applied. The work starts when somebody decides to go looking.
Drupal Has the Same Problem, With Different Wording
Several of our clients run Drupal, and the equivalent failure has a different name there: unsupported.
On July 29, the Drupal security team published three contributed project advisories. Powerful Surveys (SA-CONTRIB-2026-092) and Disable Login Page (SA-CONTRIB-2026-091) are both rated Critical and both marked unsupported, which means the security team has confirmed a real issue that the maintainer has not fixed. There is no release to update to. Those modules have to be removed or replaced. The third, Token Content Access (SA-CONTRIB-2026-090), is moderately critical, a timing attack against access token comparison, and it does have a fix in version 3.1.2.
That is two more abandoned modules in a single day. The batch a week earlier was heavier: ten advisories on July 22, five of them for unsupported projects including Email Login OTP, Commerce Elavon, and Lunr exposed filters.
An unsupported Drupal module and a closed WordPress plugin are the same condition described in different vocabulary: code that is still running on your website which nobody is maintaining any longer. And removing one is usually harder than updating one, because an abandoned module often holds configuration, content, or an integration that has to be rebuilt somewhere else before it can be taken out. This is real project work, not a maintenance ticket, and it deserves to be planned rather than discovered.
The Question Nobody Is Asking About Your Plugins
Most associations can tell you which plugins they run. Very few can tell you which of those plugins still exist as maintained projects.
A provenance audit answers it. Those are different questions, and the second one is the one that matters. For every plugin and module on your site: when was it last updated, is the project still present in the repository at all, has it been marked unsupported, how many maintainers does it have, and if it disappeared tomorrow, what replaces it? A plugin with one maintainer who has not shipped a release in three years is not a security incident today. It is a security incident scheduled for a date nobody has written down.
It also happens to be the cheapest security work available to an association, because it needs no tooling, no penetration test, and no new budget line. It needs somebody to sit down with a list once a quarter.
An honest caveat. If your association runs eight plugins and a staff member who genuinely checks them every month, you do not need to hire anyone for this. Do it yourself, write down what you find, and put a recurring calendar reminder on it. The value here is in the discipline, not in who performs it.
Why This Is the Argument for a Partner Over a Vendor
A vendor builds your website, hands it over, and answers the phone when something breaks. Under that arrangement, the thing watching your site for supply chain risk is the wp-admin dashboard. This week established what the dashboard can and cannot tell you. It cannot tell you a plugin was pulled from the repository yesterday, because core has no mechanism to say so.
Somebody has to be reading advisory feeds on a Tuesday when nothing is wrong. That is a service, and it is ongoing, and it looks like nothing at all in the months when it produces no findings. It is also the difference between hearing about a backdoored plugin from your web team and hearing about it from your board chair. Our partnership plans exist to make that kind of work routine rather than exceptional, which is a distinction we have written about before.
The Cost of Not Getting the Memo
For an association specifically, an administrator account in the wrong hands is not primarily a website problem. It is a member data problem. If your site authenticates members, connects to an AMS, processes event registrations, or stores anything about your membership beyond a name, administrator access reaches all of it. Add the credential reuse that a stolen session enables, the search rankings that spam injection destroys over months, and the disclosure conversation you may owe your board and your members, and the arithmetic stops being about a plugin.
None of that is hypothetical this week. It is the documented capability of code that was distributed through the official WordPress repository and is still installed on sites whose dashboards report that everything is up to date.
Start With an Inventory
Send us the plugin and module list from your association website, or give us access to pull it ourselves. We will run a complimentary provenance audit and tell you which of them are still live projects in the repository, which have been closed or marked unsupported, which have not seen a release in over a year, how many maintainers each one has, and what the replacement path looks like for anything abandoned. You will get back a written inventory with a specific recommendation next to every line, and a clear answer to the question you could not answer from the dashboard: what is running on your website that nobody is maintaining.