內容簡介
OwnerTrail 是一款專為監控 WordPress 外掛擁有權與供應鏈的外掛，能即時追蹤已安裝外掛的擁有者變更及提交者動態，保障網站安全，避免潛在的後門風險。
【主要功能】
• 追蹤外掛擁有權變更
• 偵測新提交者活動
• 監控沉寂後重新活躍的外掛
• 警示被放棄或撤回的外掛
外掛標籤
開發者團隊
② 後台搜尋「OwnerTrail – File Integrity Checker, SEO Spam & Malware Scanner」→ 直接安裝（推薦）
原文外掛簡介
OwnerTrail is a file integrity checker, SEO spam and malware scanner for WordPress. Every day it checks each core, plugin and theme file against the genuine release, reads any file the official checksums cannot vouch for, looking for the shapes malware takes, and requests your own pages as Googlebot to catch Japanese SEO spam: the keyword spam that shows search engines thousands of spam pages while you see a clean site. Every finding comes with plain steps: what it means, and what to do.
And who owns the plugins on your site today? Not who wrote them – who controls them right now, and who committed to them last week.
WordPress.org does not review plugin ownership transfers. When a plugin is sold, the new owner inherits commit access, their first release is unaudited, and nobody is notified. In April 2026 the WordPress Plugins Team closed 31 plugins at once after a single buyer acquired the portfolio through Flippa and planted hidden code across all of them. It had been sitting there since August 2025.
We replayed OwnerTrail’s committer checks against the public commit history of those 31 plugins. Every one would have raised a high “new committer” warning, a median of 139 days before the hidden code switched on. The hidden code itself was in the official releases, so file checksums alone would not have caught it; the change of hands is the signal.
This is a known gap, not an accusation: WordPress meta ticket #5509, “Notify users of
changes to plugin ownership”, is open and unresolved.
OwnerTrail reads the public WordPress.org plugin directory and the public plugin SVN repository, builds a record of who has committed to each of your installed plugins, and tells you the moment that record changes.
You can do this by hand: open a plugin’s directory page, read the listed author and contributors, open its SVN development log, and compare the committer names against what you saw last time. That works for one plugin, once. This does it for every plugin on your site, every day, and stays quiet until something actually changes.
What it detects
Ownership change — the listed author or the contributor list changed.
New committer — somebody with no prior history in that plugin has committed for the first time. This is the signal that precedes the attack.
Dormant then active — a plugin silent for six months suddenly ships a release.
Abandoned or withdrawn — no update in over a year, or removed from the directory entirely.
Not monitorable — premium or custom plugins that wordpress.org knows nothing about, named honestly rather than quietly ignored.
The next update waits for you – free. While a plugin’s change of owner or new committer is open, its next update is held – from the Update button, bulk updates, automatic updates, WP-CLI, and a zip uploaded over it alike – until you have looked and acknowledged the finding. A new controller’s first release is the one most likely to matter, and in the 31 plugins compromised in 2025-26 the hidden code came 41 to 321 days after the new committer, so the hold lasts up to a year. No licence, no upgrade: it is part of the free plugin.
Each plugin gets a trust score from 0 to 100. Findings you have reviewed can be acknowledged, and plugins you do not care about can be muted, so the plugin stays quiet until something genuinely changes.
Is your code genuine?
Every day OwnerTrail compares WordPress core and every plugin from wordpress.org with the official fingerprint of each file, and themes, other plugins, must-use plugins and drop-ins with the copy it first saw. A changed file, an unexpected PHP file (including any in the uploads folder) or a changed wp-config.php is reported on the Code screen and, when email alerts are on, emailed within the hour. Only file names are sent; wp-config.php’s contents are never read into a finding or an email. Updates installed by WordPress itself never raise a finding. You can open areas to change (for example the theme while a developer works on it); changes there are noted quietly.
The files that run before WordPress does (wp-config.php, index.php, wp-load.php, .htaccess, .user.ini, a physical robots.txt or sitemap) are also read for the shapes a hidden loader takes: encoded code being run, a stylesheet or image loaded as PHP, another file run before every page, search engines sent somewhere visitors are not. That catches a loader planted before OwnerTrail was installed, which a comparison with the first copy cannot. A finding names the file, what was found and the line, never the content.
Matching the first copy is never taken as proof. Every file nothing vouches for (premium plugins, themes, must-use plugins, upload and language folders) is also read for the shapes malware takes: PHP or compressed data hidden in a font or image, a file that is both an image and PHP, decoded or form input being run, remote file-manager scripts, folders with dropper names such as ext17395f, an .htaccess that switches PHP back on, and names built to sit beside genuine ones. Every file in wp-admin, wp-includes and the WordPress root is compared with the official list whatever its extension, PHP anywhere in uploads, languages, fonts, upgrade or backup folders is reported, and a planted file with a back-dated time is named. A premium plugin or theme can be verified file by file against the vendor’s own zip, uploaded on the Code screen: the zip is only read and fingerprinted, never unpacked or run, and deleted straight after. If the first full check finds anything serious, OwnerTrail says plainly that the site may already have been compromised before it was installed.
A plugin or theme that appears without being installed through WordPress, one named after another (such as “flavor-starter” beside “flavor”), and a file manager or migration tool being installed are serious findings. Installed themes that are not in use are listed: their code can still be run from the web.
A plugin you delete, in WordPress or over FTP, leaves every OwnerTrail screen at once. A folder left in the plugins directory with no plugin in it (what a failed delete or a cleanup can leave behind) is listed, and any code in it is a serious finding.
What search engines see
SEO spam hides from the site’s owner: a visitor gets a “page not found” while Googlebot gets a page of spam. Once a day, and whenever you press Test now on the Code screen, OwnerTrail asks your own site for its front page, sitemap, robots.txt and a made-up page, once as a browser and once as Googlebot arriving from a Google search, and compares the answers. Only status codes, sizes and page titles are kept, never the pages. These requests go to your own site’s address only.
Code lock
On activation, OwnerTrail locks WordPress’s built-in plugin, theme and file editors for every user, administrators included. WordPress itself recommends turning these editors off, and code changes made through them are the most common way a site is quietly altered.
One click (“Only allow code changes over FTP”, on the first-run report or the Code screen) also stops plugins and themes being uploaded, installed or deleted from the admin, including installs other plugins make through WordPress’s installer. Updates of installed code keep running. A site owner (the administrator who activated OwnerTrail) can unlock for one hour; it relocks by itself. Deactivating OwnerTrail removes every lock.
The Code screen also lists installed plugins that can change code despite the lock (those that install code, run code stored in the database, or write into plugin and theme folders), so you can decide whether you need them.
What it does not do
It does not block or delay updates, and it is not a malware scanner: it tells you that code changed, not whether the change is malicious. It does not check for known vulnerabilities — use a dedicated vulnerability scanner alongside it. This plugin answers one question that those tools do not: who controls this code now?
It also cannot see a compromise that does not involve a change of ownership. In June 2026 ShapedPlugin shipped compromised Pro updates because its own build pipeline was breached; the committer record looked entirely normal throughout, and nothing here would have flagged it. Provenance monitoring answers one question well and is silent on the rest.
Licence and brand
The code is GPLv2 or later. Fork it, read it, ship it.
The OwnerTrail name, wordmark and logo are not covered by that licence and remain the property of Decodeinfy. A fork is welcome; calling it OwnerTrail is not.
External services
This plugin contacts four wordpress.org services to do its work. The only information sent to them is the slug of each installed plugin, plus its version number for the checksum service (for the WordPress core check, your WordPress version and language; for themes, each theme’s folder name and version).
wordpress.org Plugin Information API — https://api.wordpress.org/plugins/info/1.2/. Used to read each plugin’s listed author, contributors, last update date, and install count. A plugin slug is sent with each request. Terms: https://wordpress.org/about/privacy/ Privacy: https://wordpress.org/about/privacy/
wordpress.org Plugin SVN repository — https://plugins.svn.wordpress.org/. Used to read the public commit history for each plugin, which is how committer changes are detected. A plugin slug is sent with each request. Terms: https://wordpress.org/about/privacy/ Privacy: https://wordpress.org/about/privacy/
wordpress.org plugin checksums — https://downloads.wordpress.org/plugin-checksums/. Used by the daily code check to read the official fingerprint of every file in each directory plugin’s installed version. A plugin slug and version number are sent with each request. The WordPress core fingerprints come from https://api.wordpress.org/core/checksums/1.0/ (the same service as item 1), with your WordPress version and language sent. No file contents ever leave your site: files are compared on your own server. Terms: https://wordpress.org/about/privacy/ Privacy: https://wordpress.org/about/privacy/
wordpress.org themes — https://api.wordpress.org/themes/info/1.2/ and https://downloads.wordpress.org/theme/. wordpress.org publishes no checksums for themes, so for each installed theme the code check asks the directory whether the theme’s folder name is a theme there, sending only that name, and if it is, downloads the official zip of the installed version, sending the theme’s name and version. This happens at most once per theme version, in the background; the zip is only read and fingerprinted on your server, never extracted or run, and deleted straight after. Terms: https://wordpress.org/about/privacy/ Privacy: https://wordpress.org/about/privacy/
Email digest
This plugin can also email you when it finds something. This is off by default. Turning on “Email alerts” on the OwnerTrail Settings screen makes your site email plugin findings — including plugin slugs, severities, finding descriptions, and your site’s name — to the address you configure there (or, if that is blank, your site’s administration email): serious findings within the hour, at most one email an hour, plus a daily digest. A separate Weekly summary setting, also off by default, sends a short all-clear every Monday morning with plugin counts and updates waiting. The first-run panel on the Overview screen offers a one-click “Email me when something needs attention”, which turns on the same “Email alerts” setting. All of this is sent using your own site’s outgoing mail (wp_mail()); it is not a wordpress.org service and does not involve any other third party.
Requests to your own site
The “What search engines see” check requests a few pages of your own site, from your own server, at your site’s own address (for example https://your-site.example/robots.txt). It sends no data about you or your site; the requests carry a browser or Googlebot user agent and, for some, https://www.google.com/ as the referring page, so the answer is what a search engine or a visitor from a search would get. If your site sits behind a CDN or firewall, those requests pass through it like any visitor’s.
Nothing else leaves your site. There is no telemetry, no analytics, and no tracking of any kind beyond what is described above.
