Every business running a mature CMS has a software supply chain. Nobody calls it that. It is called the plugins page: thirty to sixty pieces of third party code, written by strangers, executing with full database access, on the same machine as your customer records. You vet your accountants and your payment processor. You have never vetted these.
Your plugin list is a dependency graph with no owner
Every plugin is a dependency, and most plugins ship dependencies of their own: PHP libraries copied into the plugin folder, JavaScript bundles, remote scripts called on every page load. Your site sits at the top of a tree you never drew and cannot see. That tree, not the CMS core, is where most of your risk lives.
- ▸You did not choose most of the code. You chose a booking form. The booking form chose a PDF library, an image resizer, a charting script and an analytics endpoint. Nobody signed off on those.
- ▸There is no lockfile. A modern application pins exact versions and can reproduce them. A CMS install is a folder of code that arrived at different times, from different sources.
- ▸Copied libraries never update on their own. When a plugin copies a third party library into its own directory, that library is patched only if the plugin author notices, rebuilds and ships. Many never do.
- ▸Deactivated is not removed. Disabled plugin files still sit on disk, and some of them remain reachable over HTTP.
This pattern has its own entry in the OWASP Top 10 under vulnerable and outdated components, because it shows up again and again in real incidents.
What abandonment actually means in security terms
Abandoned does not mean broken. It means nobody will ever write the patch. The code keeps working, the flaw keeps existing, and the exploit still gets published. Abandonment converts a fixable bug into a permanent one, and attackers scan the internet specifically for the versions that are never going to move.
The signals are easy to read once you look for them:
- ▸Last release date. A plugin with no release in two years is not stable, it is unattended.
- ▸Unanswered support threads. A forum full of questions and no maintainer replies is the clearest tell you will get.
- ▸Silent removal from the official directory. Plugins are sometimes pulled after a security report. Your site keeps running the vulnerable copy and shows you nothing, because the update channel is gone.
- ▸Ownership transfer. The dangerous one. A popular plugin with a tired author gets sold or handed on, and the new owner ships an update adding tracking, injected links or a backdoor. You installed a known brand and received a stranger.
When a flaw in a widely deployed component starts being exploited at scale it tends to appear in the CISA Known Exploited Vulnerabilities catalogue, which is worth a weekly look because it separates theoretical exposure from what is being used against real sites.
The four ways a plugin ecosystem gets you breached
Almost every plugin related compromise follows one of four paths. None of them require a sophisticated attacker, none of them are targeted at you specifically, and all of them are automated at internet scale by people who will never know your company name. Recognise the four and you can prioritise.
- ▸A known vulnerable version left running. A flaw is published with a proof of concept. Scanners fingerprint the version from your public HTML or a readable readme file. Exploitation is a script, not a decision, and affected version ranges are published in the NIST National Vulnerability Database.
- ▸An orphaned plugin that will never be patched. Same mechanism, no ending. The only fix is removal or replacement.
- ▸A poisoned update. The maintainer account is phished or the build pipeline is compromised, and malicious code arrives through the legitimate update channel. It is the same class of attack as typosquatting in language ecosystems, and it defeats the advice to always update.
- ▸Nulled or pirated premium plugins. Someone saved a licence fee and installed a cracked copy from a download site. Those packages very often carry an added payload. That is the business model of the sites distributing them.
Once any of these lands the outcome is usually the same: a web shell in an uploads folder, an extra administrator account, and injected redirect code that only fires for visitors arriving from search.
Clicking update is not an audit
Updating is hygiene. It keeps you current with what maintainers chose to publish. It tells you nothing about what you are running, who wrote it, whether anyone still maintains it, or what it can reach. An audit answers those questions. Most maintenance retainers only do the first thing.
- ▸Automatic updates shrink exposure time but widen the blast radius of a poisoned release, so they need a staging step and a tested restore, not blind trust.
- ▸Nobody reviews permissions. A plugin installed for a contact form may register public endpoints, schedule background jobs and make outbound network calls. None of that appears on the plugins page.
For the uncomfortable version of this in a WordPress context, read The WordPress Security Reality Check Every Business Owner Avoids, then compare it to What Website Maintenance Should Actually Include (and What You Are Probably Paying For).
How to audit a plugin ecosystem honestly, in one working day
A real audit takes a day for a normal site, and it produces a document, not a feeling. The goal is a complete inventory with a decision attached to every line. Work from the file system and the database, never from the admin screen alone, which only shows what the CMS wants to show you.
1. Inventory from disk. List every plugin, theme, must use plugin and drop in file on the server, active or not, with version and modification dates. Compare that to what the admin panel reports. Differences are findings. 2. Record provenance. Note the source (official directory, paid vendor, agency built, unknown), the last release date, the maintainer, and whether the licence is paid and current. 3. Map capability. Answer four questions per item: does it write to the database, accept file uploads, register public endpoints, or call external services. Anything answering yes twice is a priority item. 4. Check for known issues. Match versions against published advisories, and check the exploited catalogue for anything needing same day action. 5. Look for tampering. Compare installed files against the official distribution. Modified files inside a plugin folder are the highest value finding in the exercise. 6. Attach a decision to every line. No item leaves the audit undecided.
Use The Small Business Website Security Checklist for 2026 as the surrounding control set, so the plugin audit sits inside a wider posture.
Give your CMS the SBOM it was never designed to have
A software bill of materials is a machine readable list of what your system is made of, with versions. Application teams have had this for years. CMS installs almost never do, which is why nobody can answer the only question that matters during an incident: are we affected.
Produce one in a standard format. CycloneDX is well supported by tooling, and CISA guidance on SBOM sets out the minimum fields. Keep the file in version control, regenerate it on every deployment, and diff it. A plugin in that diff which nobody remembers approving is exactly the alert you want.
This is also turning into a market requirement. The EU Cyber Resilience Act places obligations around component transparency and vulnerability handling on products with digital elements, and regulated buyers already ask for component lists.
Four honest dispositions: keep, replace, absorb, leave
Every plugin in the inventory gets exactly one of four outcomes, and deciding is the audit. A list without decisions is paperwork, and paperwork has never stopped a scanner. Write the disposition next to each line, with a name and a date against it.
- ▸Keep. Actively maintained, genuinely needed, licence current, capability understood. Put it on a review date and move on.
- ▸Replace. The function is needed, this implementation is not trustworthy. Swap it for a maintained equivalent and budget the testing rather than pretending it is a click.
- ▸Absorb. Many plugins exist to do something small: a redirect rule, a custom field, a form post to an inbox. Two hundred lines of code you own removes a permanent third party dependency and a permanent update obligation.
- ▸Leave. Sometimes the ecosystem itself is the risk. When half your inventory is unmaintained and every update is a gamble, you are paying for a platform that no longer serves you. Leaving WordPress: A Migration Playbook That Does Not Lose Your SEO covers doing that without wrecking your search performance.
What good looks like six months later
The target state is boring and measurable. You know what you run, you can prove it, and a new advisory produces a short answer within an hour instead of a week of guessing. None of this needs a large budget, only a decision that the plugin folder is infrastructure.
- ▸The component inventory lives in version control and regenerates automatically.
- ▸The number of installed extensions has gone down, because unused ones were removed rather than deactivated.
- ▸Someone reviews new advisories weekly, and the exploited catalogue triggers same week action.
- ▸Updates land in staging first, with a restore that has actually been tested this quarter.
- ▸Administrative access uses phishing resistant multi factor authentication, because a stolen admin session bypasses every plugin control you just built.
How TuniCyberLabs helps
We audit CMS and extension ecosystems from the file system up, produce a real component inventory with an SBOM you can hand to an auditor, and give you a per plugin disposition with effort estimates. When the honest answer is that the platform has to go, we build and migrate the replacement, keeping your URLs and rankings intact.
Book a plugin ecosystem audit with our team at TuniCyberLabs and get a decision list instead of a feeling.