Case studies: what OwnerTrail catches, and how
What OwnerTrail saw in real incidents, and on a test site built to be attacked: what it caught, what it could not have caught, and what it is not.
1. Thirty-one plugins, one buyer, one backdoor
A buyer acquired a portfolio of more than thirty WordPress plugins, and with them the right to publish their updates. Months later a backdoor shipped in the plugins’ official releases, and the Plugins Team closed all thirty-one at once.
Because the backdoor was in the official release, a file check had nothing to compare it with: the genuine file was the bad file. What was public all along was the change of hands. We replayed OwnerTrail’s committer check against the public commit history of all thirty-one plugins.
All 31 would have warned, 41 to 321 days before the backdoor switched on — a median of 139 days.
OwnerTrail reads every installed plugin’s public commit history each day and names a new committer the day one appears. It is free. The full replay, plugin by plugin.
2. A loader on the first line of wp-config.php
In October 2026 a live WordPress site looked normal to its owner and to every visitor. Google saw something else: thousands of Japanese spam pages, served only to its crawler.
The cause was one line added to the top of wp-config.php, the file that runs before WordPress itself. It loaded a second file, placed among WordPress’s own files and dressed as a stylesheet, and ran what it held. The code used names written in another alphabet, to slip past scanners that look for familiar words.
A checksum check alone does not cover wp-config.php: every site’s copy is different, so there is no official version to compare it with. OwnerTrail reads the files that run before WordPress for loaders — without the contents ever leaving the file — and fetches the site as Googlebot to see what search engines are shown. We rebuilt both halves of this incident on our test site with harmless markers: OwnerTrail flagged the loader as a serious start-up loader, and the spam as pages shown only to Google.
If this is happening to your site: how the Japanese keyword hack works and how to clean it up.
3. Twelve attack types, twelve caught
On 23 October 2026 we planted harmless markers with the shape of twelve kinds of attack on our own test site, and ran them through OwnerTrail’s real detection. All twelve were caught. Nothing here was done to anyone else’s site.
| Attack | How OwnerTrail sees it | Severity | Free | Pro |
|---|---|---|---|---|
| Web shell uploaded to the uploads folder | Uploads should hold no code: any PHP there is unexpected, and it is read for the shape of a shell. | Critical | Flagged and emailed | Moved to a sealed vault where it cannot run |
| PHP hidden inside an image | Media files are read at the start and the end; PHP after an image header is a disguised file. | Critical | Flagged | Quarantined |
| A function name split up to slip past scanners | Names built from pieces are put back together before the file is judged. | Critical | Flagged | Quarantined |
| .htaccess switching PHP back on in uploads | Server settings in folders meant to hold no code are read for rules that let PHP run again. | High | Flagged and emailed | The exact rule shown |
| A loader on the first line of wp-config.php | The files that run before WordPress are read for loaders. Their contents never leave the file. | High | Flagged | The changed lines shown, secrets hidden |
| A must-use plugin that tries to silence OwnerTrail | Code that hooks OwnerTrail’s own settings from outside it is flagged. | High | Flagged | Flagged |
| A WordPress core file edited, even with no internet | Compared with wordpress.org’s checksums; a file once verified stays verified offline. | High | Flagged and emailed | The changed lines, and the genuine file put back with undo |
| A new file given an old date to look original | A file’s change time is compared with its modified time. PHP can set one, never the other. | High | Flagged | Flagged |
| A dropped file that quietly creates an administrator | Code that makes an admin account without the usual checks is the classic backdoor shape. | Critical | Flagged | Quarantined |
| Spam pages shown only to search engines | The site is fetched as a visitor, as Googlebot, and as a visitor arriving from Google, and compared. | High | Flagged | Flagged |
| A new committer on a plugin you have installed | Each plugin’s public commit history is read daily; a name with no history in it is named the same day. | High | Flagged, and its next update held until you have looked (from 1.3.6) | Approve one exact version, and see what it changes |
| A plugin changing hands | A changed author or contributor list means new people can push updates to your site. | High | Flagged, and its next update held until you have looked (from 1.3.6) | Approve one exact version, and see what it changes |
What OwnerTrail is not
It detects; it does not stop a break-in. It is not a firewall and does not block requests, so pair it with one, and with backups. Code lock limits who can change code from inside the dashboard, which narrows what a stolen admin account can do, but it does not make a site unbreakable.
A file check cannot catch a backdoor shipped in an official release — that is why OwnerTrail also watches who publishes the releases. A premium plugin has no public checksums, so OwnerTrail names it as unverified until you give it the vendor’s zip to compare with.
OwnerTrail is free on WordPress.org. Holding the update of a plugin that changed hands is free, from version 1.3.6. What Pro adds — approving one exact version, restoring files, quarantine — is on the pricing section.