Plugins and code libraries stop being maintained all the time, and your website keeps running them, often without any warning. Here's why abandoned components are a growing business risk in older PHP systems, and how to find out where you stand.
Every PHP website is built partly on other people's code. A WordPress site might run thirty plugins. A business application built on a framework such as Laravel or Symfony might rely on a hundred ready-made code libraries, known as packages. Each one was written by someone, and each one depends on that someone, or someone after them, continuing to fix it.
Sometimes they stop. The developer moves on, the company behind a plugin closes, or a library is replaced by a newer one. The code keeps working, so nobody in your business notices. But it also stops receiving security fixes, and the next weakness found in it will never be repaired.
This is one of the quieter risks of ageing PHP systems. It isn't a single bug with a single fix. It is a growing share of your system that nobody is responsible for.
When the code your website relies on is quietly abandoned
In WordPress, closed plugins disappear quietly. WordPress.org, the official directory most WordPress plugins come from, can close a plugin for several reasons, including a request from its author, a breach of the directory's rules or a security issue. A closed plugin's page shows a red notice that it "has been closed and is no longer available for download". The reason appears only after 60 days.
That notice appears on the WordPress.org website, not on yours. In August 2023, the security firm Patchstack pointed out that WordPress itself doesn't tell site owners when a plugin they have installed is removed for security reasons. A vulnerable, unfixed plugin can still look perfectly up to date in your dashboard.
Patchstack's figures show the scale. It had reported 404 security weaknesses in 358 plugins to WordPress.org because the developers couldn't be reached or didn't respond. Of those plugins, 289 (71.53%) were closed, 109 (26.98%) were fixed and 6 were neither. Patchstack estimated "up to 1.6 million active installs affected". Closing a plugin stops new downloads. It doesn't remove it from the sites already running it.
Beyond WordPress, abandoned libraries keep being installed. Packagist, the main public source of PHP packages, lets a maintainer mark a package as abandoned and suggest a replacement. Developers then see a warning when they install it. The warning is easy to miss, and the package still installs.
Swift Mailer is a clear example. For years it was the standard way to send email from PHP applications, and Laravel used it before version 9. Its maintainers, Symfony, ended its maintenance at "the end of November 2021" in favour of a newer library. Yet as of 23 October 2026, Packagist records about 2.3 million downloads of Swift Mailer in the past month. It isn't alone: Packagist also flags the old Zend Framework packages and the popular Faker test-data library as abandoned, and Faker still records about 913,000 downloads a month.
What could go wrong for your business
Abandoned code rarely causes a dramatic failure on the day it is abandoned. The risk builds over time:
- Security weaknesses that will never be fixed. When a flaw is found in an abandoned plugin or library, security researchers may still report it and vulnerability databases may still publish it, but nobody ships a fix. Your site stays exposed until someone in your business acts.
- Data and downtime. A weakness in a plugin that handles forms, logins, payments or email can put customer data, orders or your website's availability at risk.
- Rising maintenance costs. Replacing one abandoned component often means testing the whole site, and the longer it's left, the more components need replacing at once.
- Questions from customers and partners. Customers and partners may ask how you manage security. "We don't know which parts are maintained" is a difficult answer to give.
Not every abandoned component is dangerous today. Many simply stop changing. The issue is that you lose the safety net: when a problem is found, there is no one on the other end to fix it.
Could your website be next?
The danger with abandoned code is not that it attracts attention. It is that published weaknesses stay open indefinitely. Once a flaw in a popular plugin or library becomes public knowledge, attackers can use automated tools to scan large numbers of websites for it. They don't need to know who you are, and a small or low-profile website is not automatically safe; it only needs to be running the affected component.
With maintained software, the window of exposure closes when a fix is released and applied. With abandoned software, it never closes on its own. Patchstack's 2023 report is a reminder of how common this is: hundreds of plugins with known, unfixed weaknesses, still installed on a large number of sites.
Having no incident so far doesn't mean your system is in good shape. Abandonment gives no warning, and the most likely way to discover it, without looking, is after something goes wrong.
Why legacy PHP applications deserve attention
Abandoned code exists in every software ecosystem. Node.js packages are deprecated and abandoned too, and a Node.js application can carry outdated components just as easily. What makes it harder in ageing PHP systems is that the way out narrows as the system gets older.
Replacements need newer PHP. Moving off an abandoned library means installing its successor, and successors are built for current PHP. Swift Mailer's replacement, Symfony Mailer, needs PHP 8.2 or newer in its current releases. An older release line still supports PHP 7.2.5 and, according to Symfony, receives security fixes until February 2029, but no version supports PHP 5. The older your PHP version, the fewer maintained replacements you can install.
Plugins are tied to old platforms. A WordPress site that can't be updated, because a theme or plugin breaks on newer versions, is often running the very plugins that were abandoned along the way.
Nobody owns the list. Many older PHP systems were built by an agency or developer who has since moved on, and nobody has a record of what is installed or who maintains it. Abandonment hides in that gap.
None of this means PHP packages are worse than anyone else's. PHP's own tooling flags abandoned packages well, and a well-maintained PHP application will catch most of this. The trouble lies with ageing systems where nobody is looking, and where acting on the findings first requires a broader upgrade.
What this means for your organisation
You don't need to be technical to ask the right questions:
- Do we have an up-to-date list of every plugin, theme and library our website or application uses?
- Do we know which of them are still maintained, and which have gone quiet?
- Which PHP version are we running, and would it let us move to maintained replacements if we needed to?
- Who is responsible for keeping track of this, and when did they last check?
If those questions are hard to answer, that is a useful finding in itself. It suggests the system has drifted to a point where nobody has the full picture, and that each individual fix is likely to cost more than it should.
Knowing what you run, and how much of it is still supported, is the foundation for any sensible decision about the application's future.
Recommended next step
Don't wait for an unfixable weakness to find you. Our free Legacy PHP assessment looks at the areas this issue touches: your PHP version, your plugins and libraries, and your hosting setup. It is designed to help you see which parts of your system are no longer maintained, where that leaves you exposed, and what modernisation opportunities exist.
We're then happy to talk through the findings with you and explore the right path. For some systems, replacing abandoned components and upgrading in place is enough. For others, the platform itself has become the constraint, and a move to the modern Node.js stack, which Sketchmonk builds on, may make sense depending on the application and your business goals. Node.js applications need the same care with their dependencies; no stack removes that work. What matters is ending up with a system someone is actually looking after.
Understand your risk before an incident forces you to.
Free Legacy PHP Risk Assessment
Not sure how much of your system nobody is maintaining? We'll review your PHP version, plugins, packages and hosting setup, and tell you plainly which components are abandoned, where you're exposed and what your options are, whether that's a patch, an upgrade or a migration.
