An Enterprise WordPress platform can be fully patched and still be unmaintained. Every critical update applied within days, no outstanding vulnerabilities, a clean scan report. Underneath that, a PHP branch nine months from end of support, custom blocks written against an editor API that core has moved past, and four plugins whose vendors stopped answering support tickets sometime last year. None of that generates an alert.
Maintenance defends against outcomes that, when the defence works, leave no evidence they were ever a threat. A quarter with no incident looks the same either way, which means the teams cutting maintenance are usually reading the evidence correctly. Nothing in the reporting distinguishes a well-run platform from a lucky one. What separates them only becomes visible in what each is exposed to.
Exposure One: The Five-Hour Window
Patchstack’s 2026 ecosystem report puts the weighted median time to first mass exploitation of a WordPress vulnerability at five hours. Not five days from disclosure to a working proof of concept. Five hours from disclosure to attackers hitting sites at volume.
That number breaks the assumption most enterprise change-control processes are built on. A patch window measured in weeks, or even in a fortnightly release train, has no useful relationship to a threat operating on that clock. The 2025 disclosure volume reinforces the point: over 11,000 new vulnerabilities across the ecosystem, a 42% increase year over year, with roughly 46% having no patch available at the moment they became public.
Worth saying plainly, since it applies to most of the security data available here: Patchstack sells vulnerability protection. So do Wordfence, Sucuri, and GoDaddy, whose telemetry appears throughout this space. The numbers are the best anyone publishes, and they are also produced by companies selling the remedy.
Core Is Not the Weak Point Anymore
The most useful counter-evidence comes from the same commercial sources, which is a reason to trust it. Sucuri’s remediation data shows the share of CMS applications outdated at the point of infection falling from roughly 60% in 2019 to 39% in 2023, and credits WordPress core auto-updates directly. Only around 37% of infected WordPress sites were running outdated core, against 97% for PrestaShop.
Core has largely solved its own problem. Plugins have not, accounting for 91% of 2025 disclosures. The exposure moved rather than closed, and it moved into the layer with the least governance.
Exposure Two: Dependencies Nobody Is Watching
The WordPress.org repository lists more than 63,000 free plugins and reviews every new submission. It does not review code when a plugin changes hands, and it does not notify site owners when an installed plugin gets closed.
That second gap is the operationally dangerous one. A plugin can be pulled from the directory over an active security issue, and the admin dashboard will look identical the next morning. No banner, no email, no entry in the updates screen. In 2024, more than 1,600 plugins and themes were removed for unpatched security issues, and a single coordinated cleanup that October closed roughly 977 of them at once.
Comparable ecosystems have tightened this considerably. npm and PyPI both added provenance controls and mandatory two-factor authentication for maintainers of widely installed packages. The WordPress directory runs a lighter model, which suits a repository built largely for small sites and suits an enterprise deployment considerably less well, particularly where a dozen extensions touch payments, authentication, or personal data.
Maintenance, in this context, means something more specific than applying updates. It means somebody knows which extensions are load-bearing, who maintains each one, whether that maintainer is still responsive, and whether the organization could take ownership of the code if the answer turned out to be no.
Exposure Three: Deadlines That Arrive Regardless
Some of what accumulates during a maintenance freeze runs on public calendars, which makes it the easiest category to plan around and the most embarrassing one to be caught by.
PHP retires one version every December. PHP 8.1 went end-of-life at the end of 2025, PHP 8.2 follows at the end of 2026, and PHP 8.3 a year after that. WordPress 7.0 sets its minimum supported PHP version at 7.4 while recommending 8.3, and the gap between those two numbers is where a lot of platforms quietly sit. PHP 7.4 has received no security patches since November 2022. Roughly one in five WordPress sites runs it anyway.
Core releases arrive on their own schedule. WordPress moved back to three major releases a year in 2026, which puts a compatibility checkpoint in front of a large platform roughly every four months, shorter than the change-approval cycle at plenty of the organizations running one. Individual releases carry breaking changes that survive a release-note skim. WordPress 7.0 replaced the admin list tables for Posts, Pages, and Media with an entirely different data layer, and classic meta boxes disable real-time collaboration on any post that uses them, quietly excluding part of an editorial workflow from the release’s headline capability.
Deprecation Without a Deadline
Classic themes present the version of this problem that is easiest to defer indefinitely. The Classic Editor plugin remains supported and has been renewed year over year. Nothing is being switched off, and no removal date exists.
What happens instead is capability drift. Gutenberg Phase 3 collaboration features are not coming to classic themes, block-based themes are the forward path, and heavily customized classic implementations face steadily widening plugin incompatibility. A soft deprecation with no deadline attached generates no urgency, no calendar entry, and the gap widens on its own schedule.
Exposure Four: Compliance That Does Not Pause
Regulatory obligations attached to a public website are continuous, and they do not accommodate a platform freeze.
Ontario’s AODA requires WCAG 2.0 Level AA for public web content at public-sector organizations and private organizations with 50 or more employees, and requires organizations with 20 or more employees to file an accessibility compliance report, with the next deadline falling at the end of 2026. The European Accessibility Act has been enforceable since June 2025 and applies to any business serving EU consumers regardless of where it is headquartered. Quebec’s Law 25 requires explicit opt-in consent before tracking technologies fire, applies based on the visitor’s location rather than the company’s, and turns consent management, cookie auditing, and data subject request handling into permanent platform work.
Accessibility raises a problem the others do not. No published study quantifies how quickly an actively edited site drifts out of conformance, so the argument runs on mechanism rather than measurement. Every page published without alt text, every uncaptioned video, every untagged PDF, and every form field added without governance introduces new failures. A site audited as conformant at launch does not stay conformant. It decays continuously as content ships, and an organization without editorial accessibility controls is accumulating findings from the day the audit closes.
Exposure Five: Degradation Nobody Files a Ticket For
Performance decline is the exposure with no incident attached and therefore no trigger to act. Around 46% of WordPress origins pass mobile Core Web Vitals, meaning the majority do not. Google treats those metrics as a ranking input using real-user data, though its own guidance positions them closer to a tiebreaker between comparably relevant pages than a dominant factor.
The conversion evidence is stronger than the ranking evidence. Deloitte’s study for Google, covering roughly 30 million sessions across 37 brand sites, found that a 0.1-second improvement in mobile site speed lifted retail conversions by 8.4% and average order value by 9.2%. Improvements that small moving numbers that large works in both directions.
No longitudinal study tracks how unmaintained WordPress degrades specifically, so the mechanism carries the claim: plugin accretion, unoptimized media, database bloat, stale caching layers, and missed PHP performance gains compound into slower pages long before anyone opens a ticket. Nothing breaks. The platform just gets worse at its job, gradually enough that no single quarter looks like the moment it happened.
Where Deferral Can Be Genuinely the Right Call
An argument that concedes nothing convinces nobody, and there are real concessions here.
Auto-updates have measurably reduced core-driven compromise. A well-hosted site with a handful of plugins and auto-updates enabled is considerably safer than the alarmed version of this argument implies. A low-traffic informational site with no regulated data, no commerce, and no active publishing can run untouched for years, and spending heavily against that risk wastes budget with better uses elsewhere.
Risk scales with reach rather than with the age of the last commit. A display plugin that has worked unchanged for three years is a different proposition from an unmaintained extension handling authentication or payment.
What Maintenance Actually Buys
Every WordPress platform runs on somebody’s schedule. Deferring maintenance does not suspend that schedule. It transfers ownership of it to a host enforcing a PHP upgrade on its own timeline, a regulator with a filing deadline, or someone scanning for a vulnerability disclosed that morning.
A maintenance budget buys the right to choose when the disruptive work happens, which is the practical difference between a planned migration and a forced one. Organizations that lose that choice tend to end up executing a rushed replatform under time pressure, sold internally as modernization, at a cost a staged approach would never have reached.
A handful of signals tend to indicate the choice is slipping away:
- Any internet-exposed critical vulnerability still unpatched after 72 hours
- An installed component appearing in CISA’s Known Exploited Vulnerabilities catalogue
- More than one major WordPress release behind for over 60 days
- Fewer than six months of PHP security runway with no validated target version
- Business-critical plugins untested against the last three WordPress majors
- Emergency maintenance consuming more than a third of engineering capacity across two consecutive quarters
- A compatibility backlog growing faster than the team retires it
Choosing the Moment
Nothing in this argument is deterministic. Deferred maintenance does not guarantee a breach, a penalty, or a collapse in organic traffic, and plenty of platforms drift for years without any of it arriving.
What deferral reliably removes is the option of choosing when the reckoning happens. The five-hour exploitation window, the December PHP deadlines, the accessibility filing dates, and the vendor who quietly stops responding are all set by parties with no interest in an internal roadmap. A maintained platform meets them on its own schedule. An unmaintained one meets them anyway, at a moment somebody else picked, usually while three other things are already going wrong.
Trew Knowledge builds and maintains enterprise WordPress platforms for organizations that would rather not find out how that goes. As a WordPress VIP Gold Agency Partner, our team handles platform modernization, security and compliance remediation, PHP and block editor migration, and the honest assessment of whether a platform is worth maintaining or worth replacing. Get in touch to talk through where yours actually stands.
