Before installing a plugin or keeping an old one, spend five minutes checking who maintains it, when it was last updated, its SVN commits, and its support threads.

Check the developer profile and ownership history

When evaluating a plugin on WordPress.org, start by looking at who currently owns and maintains the project. Ownership of popular plugins can change hands quietly when original developers sell their work to commercial entities or third-party maintainers.

To inspect the plugin maintainer on WordPress.org, follow these steps:

1. Go to the plugin page on WordPress.org.
2. Look at the sidebar under the Author field, or directly below the main title.
3. Click the maintainer's username to view their WordPress.org public profile.
4. Check how long the account has existed and what other plugins or contributions are attached to it.

A sudden shift in authorship—such as a plugin transferring from a long-time open-source contributor to a newly registered account or an aggressive marketing agency—warrants further examination. If you want to dive deeper into tracking maintainers, see our detailed guide on how to check who owns a WordPress plugin.

Look for warning flags on WordPress.org

WordPress.org displays specific indicators directly on a plugin's main page when potential issues arise or when maintenance stalls. Before downloading any zip file or clicking install, review these key metadata points on the right-hand sidebar:

• Last Updated: Check when the maintainer last pushed an update. If a plugin has not received an update in over two years, WordPress.org displays a prominent notice warning that it has not been tested with recent major WordPress releases.
• Closure Banners: If WordPress.org closes a plugin, a red or yellow banner appears at the top of the page stating that the plugin is no longer available for download.
• Tested up to: Compare the maximum tested WordPress version listed on the page against your current core version.

A closed plugin does not immediately break your site, but it means no future updates or security patches will be published through the official directory. If you discover an installed plugin has been removed, read our overview on what to do when a WordPress plugin is closed.

Inspect the public SVN commit history

Every plugin hosted on WordPress.org stores its code in a public Subversion (SVN) repository. You can view every code change, commit message, and committer account directly through your browser without downloading the plugin.

To review the public commit log:

1. Navigate to the plugin page on WordPress.org.
2. Click the Development tab in the navigation menu below the plugin title.
3. Click the link for Development Log or browse the SVN repository directly.
4. Review the recent commit entries for unexpected changes, such as new accounts pushing massive code updates after months or years of inactivity.

Pay attention to sudden modifications in obfuscated external API calls, unexpected remote file requests, or structural rewrites pushed by unfamiliar username handles. For step-by-step instructions on reading repository logs, see our guide on reading a WordPress plugin SVN commit history.

Review the support forum and user reports

The official support forum on WordPress.org provides real-time signal regarding whether a plugin functions predictably or introduces unwanted changes. User reports often highlight problems weeks before official notices are posted elsewhere.

Click on the Support tab on the plugin page and check these key areas:

• Resolved Threads: Look at the ratio of resolved to unresolved topics over the past two months.
• Specific Error Complaints: Look for threads reporting unexpected external redirects, unwanted promotional popups, unknown admin accounts, or unexplained performance drops.
• Developer Responses: Check whether the plugin team responds professionally to bug reports, or if support threads are ignored entirely.

If multiple users report that a recent update altered plugin behavior without documentation, hold off on updating or installing until the maintainers address the issue publicly.

Audit installed plugins inside wp-admin

Checking plugins is not just a task for new installations; existing plugins on your site must be checked regularly. Inactive or unmaintained plugins remain on your server's disk and can pose unnecessary risks if neglected.

Perform a quick monthly check inside your dashboard by doing the following:

1. Log in to your site and go to Plugins > Installed Plugins.
2. Filter by Inactive plugins. Deactivate and fully delete any plugin you no longer use. Leaving unused code on your server increases your attack surface.
3. Click View details on remaining active plugins to check their current version, author links, and compatibility notes directly from wp-admin.
4. Verify that the plugin author link points to the expected domain and developer.

If a plugin changes author, or its updates have ceased altogether, decide whether to keep the plugin or find an actively maintained alternative.

Automate plugin safety checks with OwnerTrail

OwnerTrail is a free WordPress plugin available on WordPress.org that checks your site and its plugins for you, every day.

It does the checks above on its own, every day:

• It checks WordPress core, plugin, and theme files against the official releases published on WordPress.org.
• It looks inside files that are not part of any official release, such as PHP in your uploads folder, for the telltale shapes of malware.
• It opens your pages the way Google does, to catch spam that hackers show only to search engines, such as the Japanese keyword hack.
• It notices when a plugin gets a new owner or a new developer, when an abandoned plugin suddenly updates, and when WordPress.org closes a plugin.
• It gives every plugin a trust score from 0 to 100, and can email you when something needs your attention.
• When a plugin changes hands, it holds that plugin's next update until you have looked (free, from version 1.3.6).
• Its Code lock means code on your site can only be changed over FTP, unless you loosen it.

In a historical replay against 31 backdoored plugins from 2025–2026, OwnerTrail generated warnings on all 31 plugins between 41 and 321 days before the backdoors activated, with a median lead time of 139 days. OwnerTrail detects irregularities and warns the site owner. It is not a firewall: pair it with one, and with backups.

Related: How to check who owns a WordPress plugin and A WordPress plugin was closed: what it means and what to do.

You open your site and it looks fine. Google has indexed hundreds of pages you never wrote. That gap is the whole trick, and it is checkable.

The Japanese keyword hack is one of the most common WordPress compromises, and one of the hardest for an owner to notice. The attacker does not deface your site. They add pages, thousands of them, selling counterfeit goods or pharmaceuticals, and they show those pages only to search engines. To you, logged in or just visiting, the site looks exactly as it did.

Why you cannot see it

The injected code checks who is asking for the page. It reads the User-Agent header, and sometimes the visitor's IP or where they arrived from. If the request looks like Googlebot, it serves the spam. If it looks like an ordinary browser, it serves your real page. This is cloaking: one URL, two different answers.

So the damage lands entirely in Google's index. Your rankings get hijacked, your listings sprout Japanese titles, and Google eventually flags the site as hacked, all while your own browser shows nothing wrong.

Where it hides

• A few lines prepended to wp-config.php or index.php, so the code runs before WordPress on every request.
• A PHP file dropped into wp-content/uploads and pulled in by an .htaccess or .user.ini rule.
• A changed core or plugin file that no longer matches the genuine release.
• A rewritten robots.txt or a fake sitemap.xml pointing Google at the spam.

How to check for it by hand

Ask your own site for a page the way Googlebot would, and compare it with an ordinary request:

curl -s https://example.com/ | wc -c
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/ | wc -c

If the two pages differ in size, title, language, or links, and you did not build them to, that is cloaking. Also search Google for site:example.com and look for pages and languages you never published.

One caution: a cloaked page does not always answer a spoofed Googlebot from the wrong IP. Serious attackers verify the request really comes from Google's address range, so a single curl can come back clean. The reliable tell is the gap between what Google has indexed and what your site actually contains.

The Googlebot canary, every day

OwnerTrail runs this comparison for you, once a day, from your own server. It requests a handful of your pages three ways, as an ordinary browser, as Googlebot, and as a visitor arriving from a Google search, and compares the answers: the title, the language, the size, the links, and any redirect to another site.

• Spam shown only to the crawler, a redirect that fires only for search visitors, or a sudden wall of links one view has and the others do not, is reported as a serious finding and emailed within the hour.
• It ignores the differences that are not cloaking: a firewall refusing a spoofed Googlebot (a 403 or 503), and the nonces, cache-busters and tracking tags that change on every request.
• No page content leaves your site.

It will not remove the spam for you, that is a clean-up job, but it ends the months of not knowing. The sooner you see the gap, the less of your ranking you lose.

Related: PHP files hidden in your uploads folder and how to check your files are genuine.

The uploads folder holds pictures and documents. It should never hold code. When it does, that code was almost always put there to run a backdoor.

WordPress writes uploads to wp-content/uploads: images, PDFs, the odd zip. Nothing there is ever meant to be executable PHP. So a .php file in uploads is one of the clearest signals of a compromise there is, and attackers know the folder is writable, rarely watched, and excluded from most integrity checks.

The shapes it takes

• Plain PHP, oddly named. A file like wp-content/uploads/2026/10/.cache.php or icon-cache.php, holding a web shell that runs whatever a request sends it.
• Polyglot images. A real image header followed by PHP, saved as .ico, .gif or .png. It opens as a picture and runs as code. A favicon named .f4812a.ico is a classic.
• Payloads inside fonts or compressed blobs. PHP or a zlib-compressed loader tucked into a .woff, .ttf or .dat file that something else pulls in.
• Execution overrides. A .user.ini or .htaccess in an uploads subfolder that sets auto_prepend_file, or AddType application/x-httpd-php .jpg, so the server runs images as PHP.

Finding them by hand

List executable code where only media belongs:

find wp-content/uploads -type f \( -name '*.php*' -o -name '*.phtml' \)
grep -rl '<?php' wp-content/uploads
find wp-content/uploads -name '.user.ini' -o -name '.htaccess'

Anything the first two commands return is worth opening. A .user.ini or .htaccess deep in uploads almost never belongs there. Do not just delete what you find until you have a copy: a backdoor is also evidence of how they got in.

What the R7 radar reads

OwnerTrail treats uploads, and the other folders where code never belongs, as code-free zones. Any PHP there is reported as unexpected. Beyond the name, it reads the file for the shapes malware takes, the same way a human reviewer would:

• PHP after an image or font header (a polyglot), and compressed or encoded payloads.
• Code that runs, decodes or includes whatever a request sends it.
• .htaccess and .user.ini rules that switch PHP execution back on.
• The same reading applied to the files that run before WordPress, such as wp-config.php and index.php, whose contents never leave the file.

On a very large uploads folder it works in short time-slices and picks up where it left off, so even tens of thousands of files get read without stalling the site.

Quarantine, not delete

Finding the file is half the job. With OwnerTrail Pro you move an unexpected file into a sealed vault in one click: it is taken out of the web root into a folder the server refuses to serve or run, under a random name with no extension, and it can be put back if you were wrong. Nothing is destroyed, and the file stops running at once. The files that would take the site down if moved, WordPress's own start-up files and known firewall bootstraps, are never touched.

Related: the Japanese keyword hack and how to check your files are genuine.

WordPress.org publishes a fingerprint for every file of every free plugin. For the paid plugin you bought elsewhere, there is nothing to check against, unless you bring your own reference.

For a plugin from the directory, checking integrity is easy: WordPress.org publishes the fingerprint of every file it ships, and wp plugin verify-checksums compares your copy against it. For a premium plugin, bought from the vendor and installed by upload, none of that exists. There is no public release, no published fingerprint, no history to read.

That is a real gap. Premium page builders, form plugins and themes are exactly the high-value targets a supply-chain attacker goes after, and they are the ones you cannot check the usual way.

First-seen is a weak reference

Most tools fall back to "first-seen": they record the files the first time they look, and tell you if anything changes afterwards. That is useful for catching a later change, but it proves nothing about the starting point. If the plugin was already tampered with when it was first installed, the bad files become the baseline, and every check says fine.

Check against the vendor's own zip

The genuine reference for a premium plugin is the zip the vendor gave you. Keep the original download. To verify a file by hand, unzip the vendor archive to a clean folder and compare:

# hash a file on the site and the same file from the vendor zip
sha256sum wp-content/plugins/acme-pro/includes/core.php
unzip -p acme-pro-4.2.0.zip acme-pro/includes/core.php | sha256sum

If the two hashes match, that file is byte for byte what the vendor shipped. Doing this for every file, by hand, across a few updates, is where it falls apart in practice.

In-memory fingerprinting on the Code screen

OwnerTrail does the whole comparison for you. On the Code screen you drop the vendor's original .zip onto the plugin or theme. OwnerTrail reads it in memory, fingerprints every file inside, and checks your installed copy against that genuine archive rather than against a first-seen guess.

• The zip is read in memory and deleted at once; it is never unpacked onto the server and never kept.
• Large archives are bounded, so a crafted zip cannot exhaust memory or disk.
• From then on, any file that differs from the vendor's release is named, and with Pro you can restore the genuine file from that same zip in one click.

What this still cannot catch

If the vendor's own build was poisoned before they shipped it, their zip and your files agree, because both are the tampered release. No fingerprint check, theirs or yours, sees that. The earlier signal is provenance: a plugin changing hands, a new name with commit access. That is why OwnerTrail watches ownership as well as code, and why it says plainly it belongs alongside a vulnerability scanner, not instead of one.

Related: how to check your files are genuine and how to check who owns a plugin.

Thirty-one plugins, one backdoor, eight months of silence. We replayed OwnerTrail's rules against what was public at the time, week by week, to see when it would have spoken up.

The short answer: yes, on all 31. Every plugin would have raised OwnerTrail's high-severity “new committer” finding, naming the account that shipped the backdoor, within a week of that account's first commit. The warning would have arrived 41 to 321 days before the backdoor switched on, with a median of 139 days.

This page shows how we tested that, what OwnerTrail would and would not have done, and the limits of the claim.

What happened

• Around May 2025 a buyer acquired a portfolio of more than thirty WordPress plugins on Flippa for a reported six-figure sum, and with it their commit access.
• The new owner's first release, on 8 August 2025, carried a backdoor. It did nothing for eight months.
• Around 5 April 2026 it switched on: it rewrote wp-config.php and injected spam pages and redirects across roughly 400,000 declared installs.
• On 7 April 2026 the WordPress Plugins Team closed all 31 plugins in a single day.

WordPress.org checks that the old owner agreed to a transfer. It does not vet the buyer, review the new owner's first release, or tell anyone running the plugin that it changed hands. That gap is documented and still open.

How we replayed it

• The data: each plugin's full commit history from plugins.svn.wordpress.org, fetched with the same request OwnerTrail makes. It is still public after the closure.
• The site: OwnerTrail installed on 6 January 2025, scanning once a week. It actually scans daily, so weekly is the cautious case.
• The rules: two of OwnerTrail's detection rules, unchanged in their logic: a first commit by an account not seen before (high severity), and a release after 180 or more days without commits (medium).
• Not replayed: the change of listed author and contributors, because the directory data for closed plugins is gone. Real installs would have had that signal too.

What it found

In the picture at the top of this page, each row is one plugin. The blue dot is the week OwnerTrail would have warned; the dark bar on the right is the day the backdoor switched on. The long grey lines are the months a site owner would have had to look, decide, and act.

What OwnerTrail would, and would not, have done

• The free plugin would have raised the finding, dropped the plugin's trust score, put it at the top of the list, and emailed the owner within the hour if email alerts were on. Since 1.2.0 it also offers one click to stop WordPress auto-updating a plugin that changed hands.
• OwnerTrail Pro would have held the update of a plugin with that open finding until someone approved that exact version, and listed the new web addresses and risky calls in the release before it installed.
• Its code check would not have caught the backdoor itself. The bad code was inside the official releases, so it matched WordPress.org's own fingerprints. The code check would have caught what the backdoor did next: the rewrite of wp-config.php, within a day in the free plugin and within fifteen minutes in Pro.

A new committer is not proof of harm. Most plugin sales are honest, and a new maintainer is often good news. OwnerTrail's job is to make the handover visible, so that a person decides rather than an automatic update.

The honest limits

• This is a replay, not a live catch. Nobody ran OwnerTrail on these sites at the time.
• A warning only helps if someone reads it. That is why OwnerTrail emails within the hour, keeps a finding open until it is acknowledged, and in Pro can hold the update until a person decides.
• It would not have caught the separate ShapedPlugin compromise, where the existing owner's build pipeline was turned against them and nothing about who held control changed.

Check your own site

You can read any plugin's history by hand: its directory page lists the author and contributors, and its SVN log names everyone who ever committed. Here is how, step by step. Doing it every week for every plugin on every site you run is the part nobody manages, which is why the backdoor sat there for eight months.

Related: the 2026 supply-chain attacks, dated and sourced and every way a plugin can change hands.

WordPress.org publishes a fingerprint for every file it ships. Comparing your files with those fingerprints is the fastest way to know whether anyone changed your code.

A backdoor has to live somewhere. Usually that is an edited plugin file, a new PHP file dropped into a plugin or into wp-content/uploads, or a changed wp-config.php. A file integrity check finds all three, without guessing at what malware looks like.

The fingerprints WordPress.org already publishes

• WordPress core: https://api.wordpress.org/core/checksums/1.0/?version=7.1.3&locale=en_US lists the MD5 of every core file for that version and language.
• Every plugin in the directory: https://downloads.wordpress.org/plugin-checksums/{slug}/{version}.json lists the MD5 and SHA-256 of every file in that release.

If your file's fingerprint matches, it is byte for byte what WordPress.org published. If it does not, something changed it.

Check by hand with WP-CLI

wp core verify-checksums
wp plugin verify-checksums --all

The first checks WordPress core; the second checks every plugin installed from the directory. Each lists files that do not match, and files that should not be there.

Where it falls short: it runs only when someone remembers to, it needs shell access, premium plugins and themes have no published fingerprints, and it says nothing about PHP files hiding in uploads.

What a complete check covers

Every day, without thinking about it

OwnerTrail runs exactly this check every day, in the background, and names any file that changed:

• A change in a part you have not opened to a developer is a serious finding, emailed within the hour.
• A change in an area you opened, such as the theme your developer is working on, is noted quietly.
• If the file is later put back exactly as it was, the finding says so, and still waits for you to acknowledge it.
• No file contents leave your site: only plugin slugs and versions are sent, to WordPress.org.

The one thing a file check cannot see

If a malicious release is published by the plugin's own author, the bad files are the official files, and the fingerprints match. That is what happened with the EssentialPlugin backdoor. The signal there is earlier: the plugin changing hands. That is why OwnerTrail watches ownership as well as code.

Related: how to lock the plugin editor and how to check who owns a plugin.

Anyone with an administrator login can rewrite your plugins from the browser. Here is how to close that door, and what each option costs you.

WordPress ships with a plugin file editor and a theme file editor under Tools and Appearance. Any administrator can open a plugin's PHP and change it, live, with no review and no record. That includes a developer you gave access to last year, and anyone who steals an administrator's password.

WordPress itself recommends turning the editors off. There are three ways to do it.

1. DISALLOW_FILE_EDIT: turn the editors off

Add one line to wp-config.php, above the line that says to stop editing:

define( 'DISALLOW_FILE_EDIT', true );

The plugin and theme file editors disappear for every user. Plugins and themes can still be installed, updated and deleted from the admin.

The catch: it is all or nothing, it lives in a file only someone with server access can change, and it does nothing about the other ways code arrives: uploading a plugin zip, or installing one that writes files itself.

2. DISALLOW_FILE_MODS: stop every change from the admin

define( 'DISALLOW_FILE_MODS', true );

This goes further. No installs, no uploads, no deletes, and no updates from the admin either, including automatic ones. Code can only change over FTP, SSH or your deployment pipeline.

The catch: you now own every update by hand, including security fixes. On a site nobody deploys to regularly, that is how plugins go stale and vulnerable.

3. A lock only a site owner can lift

The middle path: lock the editors and stop uploads, installs and deletes from the admin, but let updates run, and let a named site owner lift the lock for an hour when they genuinely need it. That is what OwnerTrail's Code lock does:

• The editors are locked the moment OwnerTrail is activated, for everyone, administrators included.
• One click allows code changes only over FTP: no editors, uploads, installs or deletes from the admin. Updates still run.
• Only a site owner can loosen it, and an hour later it locks itself again. Other administrators, including developers, cannot.
• It lists the installed plugins that could get around the lock, such as file managers and code-snippet plugins, so you can decide whether you need them.

Which should you use?

What none of them can stop

Anyone with FTP or server access can still change files and even remove the plugin that guards them. A plugin can write files with PHP directly. So a lock is half the job: the other half is noticing a change. OwnerTrail checks every code file against WordPress.org's official fingerprints each day and names any file that changed. How a file integrity check works.

Related: WordPress file integrity check and the EssentialPlugin backdoor, replayed.

A closed plugin keeps running on your site exactly as before. It just never gets another fix, and WordPress does not tell you.

The WordPress Plugins Team can close a plugin in the directory. Its page shows a closure notice, it cannot be downloaded, and it receives no more updates. On 7 April 2026 the team closed 31 plugins in a single day after a backdoor was found in all of them.

What it does not do is reach the sites already running it. The plugin stays active, unchanged, with no notice in your admin.

Why plugins get closed

WordPress.org records a short reason with each closure, such as:

• Security Issue: a vulnerability or malicious code. The most urgent case.
• Guideline Violation: the plugin broke the directory's rules.
• Author Request: the author withdrew it, often because it is no longer maintained.
• Licensing or trademark problems.

Some closures are temporary and the plugin returns once fixed. Many are permanent.

How to check whether a plugin was closed

Ask the directory's public API, replacing the slug:

https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=PLUGIN-SLUG

A closed plugin answers with "error":"closed", the closed_date, and a reason_text such as Security Issue. A plugin that is simply not in the directory answers Plugin not found.

Doing that for every plugin, on every site, every week, is the part nobody manages.

What to do when one of yours is closed

1. Read the reason. "Security Issue" means act today; "Author Request" usually means plan a replacement.
2. Turn off its automatic updates, so nothing new arrives if the listing changes hands or returns under someone else.
3. Find a maintained replacement, test it, and switch.
4. Remove the closed plugin, rather than leaving it deactivated: inactive code can still be reached on some servers.
5. Check its files against the last genuine release if the reason was security. How a file integrity check works.

Let your site tell you

OwnerTrail asks the directory about every installed plugin each day. A closed plugin becomes a high-risk finding with the closure date and reason, even if it was closed before you installed OwnerTrail. From the same screen you can turn off its automatic updates in one click.

Related: the EssentialPlugin backdoor, replayed and every way a plugin can change hands.

Everything you need is public. It takes about three minutes per plugin, and the part most guides skip is the part that matters.

There is no button for this. WordPress.org publishes everything you need, in two places, and never joins them up for you. Here is the whole method.

1. Read the directory page

Open https://wordpress.org/plugins/<slug>/ and scroll to Contributors & Developers. You get two things:

• The listed author - a display name, which is free text and can be changed at any time without any other change.
• The contributor usernames - actual WordPress.org accounts, linked to profiles.

Write both down. The author line is the one that changes most visibly when a plugin is sold, and it is also the one that tells you least, because it is a label rather than a permission.

2. Read the commit log

Open https://plugins.svn.wordpress.org/<slug>/. This is the plugin's actual repository, public, no account needed. The trunk directory is current development and tags holds released versions.

What you want is the commit history: who committed, and when. The directory page also exposes this under its Development tab, which is easier to read if you are only checking one plugin.

Note every username that appears, and the revision number of its earliest commit.

3. Compare the two lists - this is the step that matters

Listed contributors and people with commit access are not the same set. Almost every guide to this treats them as interchangeable, and they are not.

The contributor list is a directory display field. Commit access is the permission that actually ships code to your site. Someone can be added as a committer without appearing in the contributor list, and someone can sit in the contributor list for years having never committed anything.

So when you compare, ask a specific question: is there a username in the commit log that is not in the contributor list, and that has never committed to this plugin before?

That is the signal. Not the author name changing, which is cosmetic and often lags. A new committer is the first moment at which someone new can ship code to every site running that plugin.

4. Decide whether it is legitimate

Most transfers are entirely legitimate. Plugins are sold, maintainers hand over, agencies take on abandoned tools. A new name is a question, not a verdict. Three things usually settle it:

• The changelog. A real handover is often announced there, or in a release post.
• The support forum. Look for the new maintainer introducing themselves, or users asking who is running things now.
• The new username's profile. Open https://profiles.wordpress.org/<username>/. What else do they commit to? How long has the account existed? An account created last month that now has commit access to a plugin with 90,000 installs is worth ten more minutes of your time.

Then read the actual diff at that revision. Most of the time it is a version bump.

What about premium plugins?

You cannot do any of this. A plugin distributed from a vendor's own site has no public directory page and no public commit history, so there is no record to compare against. That is not a gap in your process; it is a gap in what exists.

It is worth being honest with yourself about that rather than assuming a premium plugin is safer because you paid for it. The June 2026 ShapedPlugin compromise was a premium product, shipped through the vendor's own pipeline, and no public record would have shown anything.

Doing this at scale

Three minutes per plugin is fine once. A single WordPress site runs twenty to forty plugins. An agency with thirty client sites is looking at several hundred installs, and the check is only useful if you repeat it - a transfer you looked for last March tells you nothing about one that happened in June.

Which is why almost nobody does it, and why the April 2026 backdoor sat in a portfolio of 31 plugins for eight months with the evidence public the entire time.

Related: the 2026 WordPress supply-chain attacks.

Two separate compromises hit WordPress plugins in 2026. They are usually discussed together, and they were not the same kind of attack at all.

One came through a change of ownership. The other came through a vendor's own build pipeline. The difference matters, because the defences are different and no single tool covers both.

This page is a dated record. Where something is disputed or unknown, it says so.

Incident one — the Flippa portfolio, April 2026

A buyer acquired a portfolio of more than thirty WordPress plugins through Flippa, the website marketplace, for a reported six-figure sum. The portfolio included the Essential Plugin range, with a combined install base reported at around 400,000 sites.

The buyer's first commit after taking over was a PHP deserialization backdoor.

The dormancy is the part worth sitting with. The backdoor was planted in August 2025 and did nothing for roughly eight months. In April 2026 it activated, injecting cloaked SEO spam across every site running the affected plugins. On 7 April 2026 the WordPress Plugins Team closed all 31 plugins in a single day.

Why nobody noticed

Nothing about the transfer was announced. WordPress.org does not review plugin ownership transfers and does not notify the sites running a plugin when its ownership changes. The plugins kept their names, their directory listings, their install bases and their update channel. To every site running them, the malicious release arrived as an ordinary update.

The ownership transfer itself was visible in public data from the day it happened — the listed author changed, the contributor list changed, and an unfamiliar username began committing. Anyone comparing that record against the previous week's would have seen it. Nobody was comparing.

Incident two — ShapedPlugin Pro, June 2026

Attackers compromised ShapedPlugin's own build and distribution pipeline and shipped backdoored updates of its Pro plugins between April and June 2026. It was assigned CVE-2026-10735.

The payload was considerably more aggressive than the first incident's: stolen credentials and 2FA codes, wp-config.php contents exfiltrated, WooCommerce order data taken. It hid itself from the WordPress admin plugin list, registered a REST API backdoor accepting arbitrary file writes, bundled Tiny File Manager and Adminer for direct file and database access, and installed a webshell driven by URL parameters with a hardcoded login bypass.

Ownership monitoring would not have caught this one

There was no transfer. The vendor did not change hands, the committer list did not change, and the people publishing releases were the same people as the month before. The provenance record looked entirely normal throughout, because the provenance was not what broke — the pipeline was.

Being clear about this matters more than claiming broad coverage. A tool that monitors ownership has nothing useful to say about a compromised build server. OwnerTrail would have shown nothing, and says so on its own front page.

What the two have in common

Neither was a vulnerability. Nothing in either case was a bug a scanner could have matched against a database, because in both cases the code did precisely what its author intended.

That is the structural problem. A vulnerability scanner compares your plugins against a catalogue of known-bad. Both of these arrived as new code, from the expected source, through the ordinary update channel, before any catalogue had heard of them. Most affected sites were running a scanner the entire time.

The window in which either was preventable was before the malicious release installed itself — and in the first case, that window was eight months long.

The gap WordPress already acknowledges

This is not an outside criticism. There is an open ticket on the WordPress meta tracker, #5509, Notify users of changes to plugin ownership. It is filed, it is discussed, and it is unresolved. WP Tavern has covered the question editorially more than once.

So the position today is: plugin ownership transfers are permitted, unannounced, unreviewed, and invisible to the sites affected. Everyone involved knows it.

What you can actually do

For the ownership case. The data is public. Every plugin's directory page lists its author and contributors, and its SVN repository carries the full commit history including the username behind every commit. You can read both by hand. Doing it once for one plugin is easy. Doing it weekly for forty plugins across twelve client sites is not, which is why nobody does it, which is why the April incident ran for eight months.

For the pipeline case. Ownership data will not help you. What helps is staged updates rather than automatic ones, a delay between a release and its installation on production, file-integrity monitoring, and reading the changelog of anything that ships a surprise release.

For both. Reduce the plugin count. Every plugin is a party you have chosen to trust with code execution on your site, and the transfer of that trust does not require your consent or your knowledge.

Timeline

Sources

• InfoQ — Attacker Bought 30 WordPress Plugins on Flippa and Backdoored All of Them
• TechCrunch — Someone planted backdoors in dozens of WordPress plug-ins
• The Hacker News — ShapedPlugin WordPress Pro Plugins Backdoored in Supply Chain Attack
• Security Affairs — ShapedPlugin Supply Chain Attack Backdoors Pro Plugin Updates
• WordPress meta trac #5509 — Notify users of changes to plugin ownership
• Plugin Handbook — Transferring Your Plugin to a New Owner

Related: the Flippa backdoor, replayed against OwnerTrail, how to check who owns a plugin and every way a plugin can change hands.

You are trusting whoever controls each plugin on your site today, not whoever wrote it. Here is every way that person changes.

WordPress.org permits every route below, requires an announcement for none of them, and notifies the sites running the plugin about none of them either. They differ in how visible they are, and that turns out to matter more than how they happen.

1. Outright sale

The most discussed route, because it is the one behind the April 2026 incident: a portfolio of 31 plugins bought through Flippa and backdoored across the lot. Marketplaces list WordPress plugins openly, priced on install count.

Visibility: good, after the fact. The listed author usually changes and new usernames appear in the commit log. Nothing announces it, but the public record does move.

2. Adoption of an abandoned plugin

WordPress has a formal process for taking over a plugin whose author has stopped responding. Someone asks the Plugins Team, the team tries to reach the original author, and if there is no response the plugin can be reassigned.

Visibility: good. This is the most legitimate route there is - it exists to keep useful code alive - and it still puts a stranger's commit access on your site without telling you.

3. A committer quietly added

The plugin owner grants commit access to another account. No sale, no transfer, no change to the listed author. The original maintainer is still there and still in charge.

Visibility: poor, and this is the important one. Nothing on the directory page need change at all. The only evidence is a username appearing in the commit log that was never there before. It is also the route that most resembles a compromised maintainer account, because from the outside those two look identical.

4. The maintainer's company changes

The person is the same; the organisation behind them is not. An agency is acquired, a solo developer joins a company that takes over their plugins, a product is folded into somebody else's suite.

Visibility: mixed. The author string may change while the committers stay identical, or the reverse. Often the first public sign is a rebrand in the readme.

5. The maintainer walks away

Nobody takes over. Commits stop, the plugin keeps working, and it stays installed on every site that had it. There is no transfer here at all - which is exactly the problem, because an unmaintained plugin with an install base is what the buyers in route 1 go shopping for.

Visibility: good, if you are looking at dates. A plugin with no release in eighteen months is telling you something.

6. The account is compromised

Not a transfer, but indistinguishable from one at the moment it happens. The credentials of someone with commit access are stolen and used.

Visibility: depends entirely on whether the attacker commits under the existing account or adds a new one. If they use the existing account, no provenance signal moves at all - which is what happened with ShapedPlugin in June 2026, where the build pipeline itself was breached and the committer record looked completely normal throughout.

What this ordering is actually telling you

Routes 1, 2 and 4 are reasonably visible in public data. Route 5 is visible if you watch dates. Route 3 is visible only if you are comparing committer lists over time. Route 6 may not be visible at all.

So no amount of provenance monitoring gives you complete coverage, and anyone selling you that is overstating it. What it gives you is the four or five routes out of six where a public record does move - and in the April 2026 case, that record moved eight months before anyone noticed the payload.

What a site owner can do

• Know which plugins you would not notice losing. Those are the ones to remove. Every plugin is a standing grant of code execution to whoever holds commit access this week.
• Watch committers, not author names. The author string is a label. Commit access is the permission.
• Stage updates rather than applying them automatically on sites that matter. A delay of a few days costs little and is the only defence that also covers route 6.
• Treat premium plugins as unmonitorable, because they are. No public record exists to compare.

Related: how to check who owns a plugin and the 2026 supply-chain attacks.

Every plugin in the directory has a public repository. Most people never open one. It answers questions the directory page cannot.

WordPress.org hosts every directory plugin in Subversion, publicly readable, no account required. The URL is predictable:

https://plugins.svn.wordpress.org/<slug>/

You can open that in a browser. You do not need an SVN client for anything in this article.

The layout

Three directories, and the convention is strict:

• trunk/ - current development. For most plugins this is what the next release will be built from.
• tags/ - one directory per released version. tags/2.4.1/ is exactly what shipped as 2.4.1, frozen.
• assets/ - the banner, icon and screenshots for the directory listing. Not shipped to sites.

The Stable tag line in a plugin's readme.txt decides which of those tags directories is actually served to users. This is the single most misunderstood mechanism in the directory: the version people install is whatever Stable tag points at, not the highest number in tags/ and not trunk.

Reading the log

The easiest route is the directory page's Development tab, which renders the recent history with revision numbers, usernames and dates.

Revision numbers are global across the whole plugin repository, not per plugin. A commit at r3318812 tells you when it happened relative to every other plugin, which is occasionally useful and often confusing the first time you see it.

What you are reading for:

• Which usernames appear, and when each first appears.
• The gap between commits. Eighteen quiet months followed by sudden activity is worth a look, particularly if the committer is new.
• What actually changed. A version bump and a readme edit is not the same as a new file in includes/.

Spotting a first-time committer

This is the signal worth the effort, and the log gives it to you directly: a username whose earliest revision in this plugin is recent.

Be careful about one thing - the person may be well known elsewhere. A committer with ten years of history across core and forty plugins, appearing in this one for the first time, is a different proposition from an account created six weeks ago. Open https://profiles.wordpress.org/<username>/ before drawing a conclusion.

The question is never "is this person trustworthy". It is "did the set of people who can ship code to my site change, and do I know why".

Reading an actual change

Browsing to a file in trunk/ shows its current content. To see what a specific revision changed, an SVN client is genuinely easier:

svn log -v -r 3318812 https://plugins.svn.wordpress.org/<slug>/
svn diff -c 3318812 https://plugins.svn.wordpress.org/<slug>/

The first lists the paths touched; the second shows the change. On a plugin you are worried about, the paths alone usually answer the question.

What the log will not tell you

Three things, and they matter:

• Who authorised the commit. SVN records the account that committed, not whether that account was in the right hands at the time.
• Anything about premium plugins. Code distributed from a vendor's own site is not here at all.
• Whether the code is malicious. You are reading provenance, not behaviour. A backdoor committed by the legitimate owner looks exactly like any other commit - which is the whole difficulty.

Doing it in practice

For one plugin you are suspicious about, this takes five minutes and is worth doing properly. For forty plugins across a dozen client sites, repeated weekly, it is not a realistic manual task - and a check you do once is close to worthless, because it establishes a baseline and then never compares against it.

Related: how to check who owns a plugin.

You did not choose most of the plugins you maintain, and you will still be the one answering for them. This is a routine that fits in an hour a month.

Written for the case where you carry ten to fifty client sites, inherited most of their plugins, and have no mandate to rip half of them out.

Once, per site

• List every plugin, with its slug and origin. Directory or premium. The split matters more than the count, because only one half has a public record to check.
• Record the listed author and the contributor usernames for every directory plugin. This is your baseline. Without it, later checks compare against nothing.
• Record the last release date. Anything past a year is already a candidate for replacement, whoever owns it.
• Mark the plugins that could not be removed without a conversation. Usually far fewer than the number installed.

This is the boring part and the part that makes everything after it possible. A provenance check with no baseline is just a description of today.

Monthly, per site

• Has any listed author changed?
• Has any username appeared in a commit log that was not there last month? This is the one that matters; see the method.
• Has anything dormant suddenly shipped? Quiet for a year, then a release, is worth five minutes.
• Has anything been removed from the directory? Closure is often a security action, and the plugin stays installed and working on the site regardless.

When something fires

A new committer is a question, not an incident. In order:

1. Read the diff at that revision. Most of the time it is a version bump.
2. Open the new username's WordPress.org profile. What else do they commit to, and since when?
3. Check the changelog and support forum for an announced handover. Legitimate transfers are usually stated somewhere.
4. Then decide: accept it and record that you did, hold updates on that plugin for a fortnight, or start planning a replacement.

Record the decision either way. The value of this routine is largely that you can show your working later.

Telling a client

Most of the time you should not. A legitimate transfer is not news, and an agency that reports every ownership change trains its clients to ignore them.

Say something when there is a decision for them to make: you want to replace a plugin they rely on, or you are holding updates on something that matters, or a plugin they paid for has been closed. Lead with what you are doing about it. "Plugin X changed hands, we have held its updates for two weeks while we watch it" is a sentence that builds confidence. "Plugin X changed hands" on its own just moves your anxiety to them.

What this routine does not cover

Being straight about the gaps, because they are real:

• Premium plugins. No public record, nothing to compare. They are not safer for being paid; the June 2026 ShapedPlugin compromise was a premium product whose own build pipeline was breached.
• A compromised maintainer account. If an attacker commits as the existing owner, no provenance signal moves at all.
• Malicious code from a legitimate owner. You are checking who, not what. That is what your scanner is for.

Provenance monitoring covers one layer. Run it beside vulnerability scanning and staged updates, not instead of either.

The honest problem with doing this across a fleet

Everything above is per site. Thirty client sites means thirty baselines and thirty monthly passes, and the routine's whole value depends on doing it consistently rather than when you remember.

That is the point at which people stop, and it is worth saying rather than pretending an hour a month scales linearly to thirty sites. If a single view across every site you manage is what you actually need, the honest answer today is that per-site tooling will not give you one.

Related: every way a plugin can change hands.