Joomla 3 Didn't Fail. Your Retainer Did.

Do you want to bury your head in the sand?

It is a real question, because burying it is a defensible commercial decision right up until the morning it is not. Joomla 3 reached end of life in August 2023. The paid eLTS programme that extended it ended on 17 February 2025. Since then there has been no official security patch for the Joomla 3 core at any price, from anyone.

And yet, as I write this, mySites.guru is monitoring 30,305 live Joomla 3 sites.

Before you read another number in this post, understand where all of them come from, because it changes what they mean. Every figure here is measured across sites connected to mySites.guru. These are sites whose owners pay us every month so that somebody is watching: so the installed extensions are inventoried, so a new vulnerability raises a flag, so updates can be pushed in bulk. By any reasonable definition these are among the best looked-after Joomla sites in the world.

So everything below is the good end of the ecosystem. Joomla powers millions of sites, and the overwhelming majority of them have nobody doing any of this. They are not in these statistics, and there is no reason at all to think they are doing better.

I am not writing this to tell you those sites are a risk. You know that. Every agency I have ever spoken to knows that. I am writing it because we finally have enough data to say something more useful, and more uncomfortable, about why they are still there.

The Joomla 3 dates, for the record

Most arguments about Joomla 3 run on a vague sense that it is old. The dates are more useful than the feeling, because they show how long the gap has been open and how much of that gap somebody was still being paid to cover.

Every release date below is read from the RELDATE constant compiled into that release’s own source code, so it is the date the software itself reports rather than a wiki’s recollection of it.

That 1,019 day row compresses the whole story into one line. Joomla 3.9 in October 2018 was the last release that added features for their own sake. Joomla 3.10 was a bridge built to get people off, complete with deprecation warnings and a pre-upgrade check, rather than a version anyone was meant to settle on. Most of the estate settled on it anyway, and thousands of sites never even got that far, as the next section shows.

The lifecycle dates are the ones that matter in a conversation with a client:

Two more facts worth having to hand when somebody tells you this is a small legacy problem.

Joomla 3 shipped 106 stable releases, which is more than Joomla 4, 5 and 6 have managed between them so far. It was supported for ten years and ten months, about two and a half times as long as Joomla 4 lasted. That length is exactly why so much of the web still runs it, why so many extensions were built against it, and why the people who built those sites had every reason at the time to believe they were building on something stable.

The final release also still declares its minimum PHP as 5.3.10, in administrator/index.php, unchanged since 2012. PHP 5.3 left security support in August 2014. Joomla 3 never raised that floor across its entire eleven year life, which is the root of the hosting problem further down this post: the sites are not only running old Joomla, they are running old Joomla on a PHP branch their host is preparing to remove.

Dates are one way to remember a release. Basic Joomla Tutorials marked this one twice, and the pair is worth your time if you ever built anything on Joomla 3.

First the warning, with a month left on the clock:

Then the look back, recorded on Joomla 3’s last day before end of life:

The Joomla 3 estate is worse than the version number suggests

Being on Joomla 3 is not one problem, it is a stack of them, and the stack has been growing for three years.

Start with the version spread. Of those 30,305 Joomla 3 sites, only 9,638 are on 3.10.12, the final release. The other 20,671, which is 68.2%, are behind even that. There are 1,286 sites sitting on 3.6.5, 1,054 on 3.4.8, and 574 on 3.3.6. These are not sites that reached the end of the road and stopped. They stopped somewhere earlier and the road ended without them.

Then the extensions. Across those sites we currently count 22,195 installed extensions with a known published vulnerability. Three sites are running twenty of them. A hundred and seventy-one sites are running thirteen or more.

The extensions doing the most damage are not obscure:

Six of the eight cannot be fixed without rebuilding the site onto a supported Joomla. Three of those six are the same vendor, cut on the same day, and two of the CVEs sit in a shared library that every Regular Labs extension bundles.

None of that is theoretical.

And remember whose sites those are. That 4.90% is the hacked rate among Joomla 3 sites that somebody is paying to have monitored.

Joomla 4 is the part that should worry you

One number changed what this post was going to be, and I did not expect it.

We ran the same vulnerable-extension analysis across every Joomla branch. Joomla 4, the version agencies migrated to specifically so that this would stop being a problem, is now the worst-maintained branch on our entire estate.

Two different things are wrong, and they are wrong on different branches. Joomla 4 has the widest spread: half of those sites are running something with a known hole in it. Joomla 3 has the deepest infestation: when a Joomla 3 site is affected it is running 3.30 vulnerable extensions, not one.

Every one of those rows is a managed site. Half of all Joomla 4 sites that somebody is paying to look after are running at least one extension with a known, published vulnerability. That is more than double the Joomla 3 rate and more than three times the Joomla 6 rate. Joomla 4 has itself reached end of life, so these sites are in exactly the position their owners paid to escape, except this time they paid first. And it went out with far less noise than Joomla 3 did. Joomla 3 got its own farewell announcement, an eighteen-month paid support programme and a warning in the admin panel. Joomla 4’s last release was 4.4.14 on 30 September 2025, and the series left security support that October with no announcement of its own at all, just a subordinate clause in the post announcing Joomla 6.

Joomla 4 did reach end of life on its own account, with bug-fix support ending in October 2024 and security support in October 2025, and you can read that anywhere. That is a statement about whether the core gets patches, which is a different question from the one I am asking.

The point is the extension column. Whether or not the Joomla 4 core is supported has no bearing on whether somebody updated RSForm! on that site last month. Nobody is looking after those 50.6%, and they are also the sites that had the most money and effort spent on them in the last three years. Blaming the Joomla project for that would be convenient and wrong.

The agencies who did the hard thing, who got the budget approved, who spent the weekends rebuilding templates and replacing extensions that had no successor, are measurably in a worse state than the ones who did nothing.

Migrating is still the only real answer, so read none of this as an argument against it. The argument is that migrating was never the thing that fixed it, and treating it as the fix is what put those sites back in the hole. A Joomla 4 site can even be hurt by trying to do the right thing: an administrator chasing security patches on an end-of-life version can switch update channels and get flung onto the next major release, breaking extensions and ending up worse off than before.

The migration was a payment. The site is a running cost. When the payments stopped, the debt started accruing again the same week.

Joomla 3 is not actually that insecure

Having spent five hundred words telling you the sky is falling, let me argue the other side, because the honest version of this is more useful to you than the alarming one.

Joomla 3 is a mature, well-tested codebase. It had eleven years and twelve point releases to have its corners knocked off, and it shows. Of the twelve core advisories Joomla published in 2026 whose affected range reaches back into 3.x, exactly one is rated High by the Joomla project. The rest are Low or Moderate. That is not the profile of software falling apart.

And look again at our own number the other way up. 95.1% of the Joomla 3 sites we monitor are not flagged as hacked. Joomla 5, fully supported and receiving every patch, sits at 2.67%. Joomla 3 is roughly twice as bad, not a hundred times.

The core is also patchable, which people forget. The community backport closes the published core holes without an eLTS licence, and it has been kept current: four more CVEs were added to it over summer 2026.

What surprises people most is that plenty of extension vendors did back-patch Joomla 3 in 2026, in some cases for free and in some cases the same day they patched the modern branches. JCE shipped a free patch reaching back to 2.7.x. iCagenda published a release literally titled “Security Release Joomla 3”. SEBLOD patched three branches on one day. J2Store, now a volunteer fork of a sunset product, fixed all six of its CVEs on the Joomla 3 branch the same day as the Joomla 4 and 5 builds. RSJoomla never dropped Joomla 3 at all and was shipping Joomla 3 builds this month.

So a Joomla 3 site running a well-chosen stack, with the core backport applied and every vendor still shipping, can be well-patched today. I would not call it supported, and I would still move it. But it is not the burning building the first half of this post implies.

That distinction is the whole argument in one turn.

The risk was always the specific set of extensions on the specific site, and whether each of those vendors happened to keep going. “Joomla 3” was never the useful unit. That is not knowable from the version number, it is not knowable from a blog post, and it changes without anyone announcing it. Two Joomla 3 sites built the same year by the same agency can be in completely different states today, entirely because of which page builder each one happened to use.

Which means the safe Joomla 3 sites and the dangerous ones are separated by whether anybody is looking, not by which version they run.

The well-meaning Joomla 3 rescue projects are not a plan, they are a liability themselves

Every time a platform goes end of life, a handful of projects appear promising to keep it alive. Joomla 3 has several, and they are not equal.

But be clear about what any of them can and cannot do for you, because three structural problems apply to all of them.

The core is not what is getting you hacked

Look back at that extension table. The three most-installed of those extensions are a template framework, a page builder and an editor, and no core fork touches any of them. This is the whole reason we treat our own patch tool as a holding position rather than a fix, and it is why a patched extension on an unpatched core, or a patched core under an abandoned template, is a safer position and not a supported one.

The version numbers break every tool that could see the problem

Joomla 3 ended at 3.10.12. A fork that calls its releases 3.11, 3.13 or 3.15 is not following semantic versioning and, more practically, it is emitting a version string that nothing in the ecosystem can interpret. Joomla’s own updater cannot reason about it. Vulnerability databases key their affected-version ranges on real Joomla releases. WAF rules and hosting-side scanners do the same. So do we: we are an inventory tool, and a site reporting a version that never existed is a site we cannot honestly tell you is safe or unsafe. We have already seen exactly this failure with vendor patches, where JoomShaper reused the same version string across two different security releases and no inventory tool could tell a patched site from an unpatched one. A fork that invents version numbers has the same problem permanently and by design.

Calling it Joomla is a problem for the reader, not just the lawyers

A fork that keeps the Joomla name and the Joomla branding while shipping code the Joomla project did not write and will not support leaves a client, a hosting provider and an incoming developer with no way to tell what they are actually running. Joomla is a registered trademark and the project has a policy about this, which is its business rather than mine. Mine is that “we are on Joomla 3.15” is a sentence that sounds reassuring and means nothing.

The PHP 8 work solves a different deadline

The PHP 8 compatibility work deserves a separate word, because it is the most useful of the lot and the most likely to be misread. Getting a Joomla 3 codebase running on PHP 8 solves a real and urgent problem, which is the next section. It does not make the site secure. Those are two different deadlines that happen to be arriving at the same time, and clearing the first one does nothing about the second.

Nobody knows when your extensions stop being supported, including the vendors

If you want one reason a Joomla 3 site cannot be managed by looking things up once and writing the answer down, this is it.

I went through the dated announcements and changelogs of the vendors whose extensions actually appear on the sites we monitor. The pattern that emerged had nothing to do with who dropped Joomla 3. The vendors who made the most absolute statements were the ones who broke them.

Akeeba shipped a release in August 2023 whose notes were titled “Final version for Joomla! 3”. It was followed by four more Joomla 3 releases, the last in May 2025, three months after Joomla’s own paid support programme had closed. Along the way they published three different end dates, including one announced two days after the deadline it replaced.

JoomShaper announced on 9 July 2026 that Joomla 3 would get “no security patches, regardless of severity”, and then shipped Joomla 3 security patches six days later, with two more following on 22 July and 27 August. That sentence is still on their site, uncorrected, while the third patch sits in their GitHub releases. We covered the announcement, the reversal and the third patch as they happened. At the same time, SP Page Builder 6.8.0 added a version check to stop the installer running on Joomla 3 at all. Hard-blocked in the mainline, separately patched on the side.

JCE announced that version 3.0 would remove Joomla 3 support. Then they lowered the Joomla 3 floor from 3.10 to 3.9, backported a free security patch to branches that predate Joomla 4 entirely, and today the Joomla 3 branch has a more recent release candidate than the 3.0 that was supposed to replace it. (Their June 2026 security post credits my own analysis for that one, which is the only reason I noticed how far the J3 branch had drifted from the announcement.)

Joomlashack said in August 2023 that they would reassess Joomla 3 support in August 2024. That sentence is still on their documentation page today, two years after the reassessment date, and the reassessment was never published.

And the spread is enormous. Kunena stopped supporting Joomla 3 in December 2022, eight months before Joomla did. Community Builder stopped on 21 August 2026, three years and four days after. Both are community projects of similar standing. RSJoomla, HikaShop and VirtueMart have not stopped at all and were still shipping Joomla 3 builds this month.

So when somebody asks whether the extensions on a Joomla 3 site are still supported, there is no date you can look up. The answer is different for every extension, it moves, and the vendors themselves keep changing it. The only way to know what a site is actually running, and whether a fix exists for it, is to check the sites continuously. That is not a pitch for our product, it is the reason a product like ours exists at all, and it is the clearest possible argument that this is a service rather than a task.

Every Joomla 3 policy statement we could find, with its link

The section above is the argument. This is the evidence, so you can check it rather than take my word for it.

We went looking for a public, dated, quotable statement from every vendor whose extensions actually appear on the sites we monitor. Every URL below was fetched and the sentence read in context, and a vendor only appears here if there is a real statement to quote. Where a page shows no date, the table says undated rather than guessing one.

Thirty statements, and no two of them agree on anything. Some are two years before Joomla 3 reached end of life, some are three years after. Nine of the thirty give no date at all, which means a customer reading the page cannot tell whether it was written last month or in 2021.

Where the actions contradict the words

The JoomShaper, JCE and Akeeba reversals are above. They are not the only ones, and the pattern is consistent enough to be worth naming: the loudest announcement is the least reliable predictor of what the vendor will actually do next.

Seblod’s only public words on Joomla 3 remain that May 2023 post, yet SEBLOD 3.30.0 shipped on 28 July 2026 fixing an SQL injection, a search-radius SQL injection and a path traversal, three years past end of life.

Web357 went the other way entirely and added Joomla 3 compatibility in June 2026, nearly three years after EOL.

iCagenda contradicts itself in the customer’s favour. The roadmap says 3.9 was the last series to support Joomla 3, while the changelog lists 3.9.15 in June 2026 and 3.9.16 in August 2026, both labelled “Security Release Joomla 3”.

Balbooa reversed under pressure from its own users, moving from “no future version will be compatible” in April 2025 to publishing and hosting a Joomla 3 compatibility patch in July 2026, credited to a community member.

YOOtheme said nothing at all for twenty-nine months while shipping Joomla 3 fixes in 4.3.7, 4.4.11, 4.4.12 and 4.5.3, and still contradicts itself: ZOO, the same company, currently advertises “Requirements: Joomla 3.x+”.

And OS Property announces “Discontinued Joomla 3 Support” on a page whose own specification box, directly above the announcement, reads “Compatible: Joomla 3.9.0+”.

The ones that said nothing at all

This list matters as much as the table, because a vendor with no statement is the common case rather than the exception. We checked and found nothing public from HikaShop, RSJoomla, StackIdeas, iJoomla, JomSocial, EShop, Phoca, JoomUnited, Falang, OSTraining, JoomlArt, Gavick, Ordasoft, ARI Soft and TemplateMonster. Several of them are still shipping Joomla 3 builds. None of them will tell you when that stops.

Three did not stop so much as vanish. MijoShop’s domain now serves a Thai football and casino blog, and the Wayback Machine shows it had already become that by November 2023, three months after Joomla 3 went end of life. VinaGecko’s domain redirects to a betting site. Xmap’s repository was archived with its last commit in September 2020.

That is the real answer to “is this extension still supported”. For fifteen of the vendors on the sites we monitor, there is no answer to look up, and for three of them the company that would have answered no longer exists.

Your host is about to decide just how long you have left for Joomla 3, and it is out of your hands

Here is the part that turns a deferred decision into an emergency, and it has nothing to do with Joomla.

Joomla 3 needs an old PHP branch. Hosting providers are removing those branches, on their schedule, and they are not asking. When your host drops PHP 7, a Joomla 3 site that has not been made PHP 8 compatible does not degrade gracefully. It stops.

Worse, on some hosts the change is a one-way door. Fasthosts is the example I keep running into: a customer switches a site to PHP 8 to see whether it works, discovers it does not, and then finds there is no route back to PHP 7. The test is the migration, and it is irreversible. So the sensible, cautious thing an administrator does, which is to try it and see, is the exact action that takes the site down with no undo.

That reframes everything above. Your real choice is between migrating on a date you pick, with a staging site and a rollback plan and a budget conversation you had in advance, and migrating on the date your hosting provider picks, at whatever hour they picked it, with the client on the phone. Migrating later was never one of the options.

And I want to be careful about who the villain is here, because it is not the host.

A host that removes PHP 7 is doing its job. PHP 7 left security support years ago. A host still serving it in 2026 is running an unpatched language runtime underneath every customer on that box, including the ones who did everything right and are simply sharing a server with you. That is not a favour to anybody.

So if your host is not forcing PHP upgrades, do not read that as generosity. It is neglect, and it is a reason to leave rather than a reason to stay. A webhost still handing out PHP 5 or PHP 7 in 2026 is telling you exactly how much attention the rest of that platform gets. The hosts causing you grief in this story are the good ones.

The PHP version each site runs is not a technical detail buried in a control panel. Across a portfolio of Joomla 3 sites it is a countdown timer that somebody else is holding, and you want it held by somebody who winds it.

Why the sites are still there, honestly

It is worth saying that this is rarely neglect, because the standard telling of this story insults the people living it.

A Joomla 3 to Joomla 5 or 6 move is closer to a rebuild than a version bump. The template usually has no direct successor. Two or three extensions the site depends on were abandoned years ago and the functionality has to be rebuilt or replaced. Nobody can quote it accurately upfront, which is why we will not quote a fixed fee for one either.

So it becomes a cost conversation the client has to agree to. And every agency owner reading this already knows how that goes, because from where the client is sitting, the site works. It loads. The contact form arrives. The phone rings. You are asking for four or five figures to deliver something that, on the day it completes, looks exactly the same as it did the day before.

That is a hard sell. I am not going to pretend otherwise.

But notice what has actually gone wrong, because it did not go wrong in that conversation. It went wrong years earlier.

The Real Reason Agencies Avoid Joomla Updates

We posted the numbers above to social media, and a comment underneath it is worth answering properly rather than in a reply box, because it names the reason most agencies actually give for staying on an old version.

That is a fair description of what agencies experience, and not a rare one either, I hear a version of it constantly. But the word doing the damage is “updates”. The incompatibilities are real. The cause is usually not the update itself.

Joomla is not good at communicating breaking changes in enough detail, and it does not reliably honour its own deprecation notices: the core team has pushed deprecation deadlines back after the fact more than once, and the backward-compatibility guarantees fall well short of what a project like Symfony offers over a comparable timeframe. Extension developers are, on the whole, not much better at tracking the breaking changes that do get published. Plenty of them find out by reading the core source rather than a changelog, and some of the consequences they hit were never fully thought through or tested by the Joomla project in the first place.

So the incompatibility is real, but “the update broke it” undersells what happened. A change shipped with too little warning, on a promise that did not hold, and the extension author had no reliable way to see it coming even while looking for it. That is less a reason to distrust updating and more a reason to distrust how the ecosystem tells you what is about to change: read the actual diffs before a major version, do not trust a changelog to be complete, and budget time for the surprises rather than assume there will not be any.

Software is a child, not a purchase

Most of those 30,305 sites were sold as a project. A price, a launch date, a handover, an invoice. Maybe a support period measured in weeks. And then nothing, until the day something breaks or a version goes end of life and somebody has to ring the client and ask for money to fix a problem the client did not know they had.

Of course they say no. From their side you sold them a finished thing and now you are asking them to pay for it again.

The framing is wrong, and it has been wrong across our whole industry for twenty years. A website is a purchase that never completes, always a work in progress. It is much closer to having a child.

The investment at the start is enormous and everybody expects it. Then there is a long steady cost that never stops: feeding it, clothing it, keeping it warm. There are predictable spikes at known milestones, when it starts school, when it goes to university, when it needs help with a first house. And there are the emergencies, the ones that arrive without warning and have to be paid immediately, because the alternative is unthinkable.

Nobody has a child and considers the job finished at the birth. Nobody budgets for a single payment and is then outraged when the child needs shoes at seven and a laptop at fourteen. And crucially, the investment does not stop when they leave home. It changes shape and it usually gets less frequent, but a parent who says “I paid for the pram, we are done” is describing an abandonment, not a completed project.

That is what a Joomla 3 site is. It is a fourteen-year-old that nobody has bought shoes for since it was three.

The client who “would not invest” was, in most cases, never actually asked to. They were sold a pram.

Why we have never sold a lifetime licence

I should declare an interest here, because this argument is the reason mySites.guru is priced the way it is, and I would rather say that out loud than let you find it in the pricing page and wonder.

We have never offered a lifetime deal. Not once in fourteen years of trading, and we get asked for one regularly.

A lifetime licence is a promise to maintain something forever, in exchange for a single payment, made once, at the moment the customer’s enthusiasm peaks and your costs have not started yet. It is the model I have spent this whole post arguing against. It is the pram, sold as the childhood. Every lifetime deal in this industry either ends with the vendor stopping the work, or with the vendor going out of business, and in both cases the customer discovers the meaning of the word lifetime rather late.

We take a subscription because the work never stops. Somebody has to read the Joomla Security Centre the morning it publishes. Somebody has to write the detection rule, test it against real sites, and ship it. That is a daily cost, so it is funded by a daily-cost model.

Here is the whole price list. mySites.guru is GBP 19.99 a month, or GBP 199.99 a year, which is about 16.6% off, so paying annually is roughly two months free. That is for unlimited sites. If you have one site, there is a GBP 5.00 single-site plan.

Unlimited means unlimited. We have subscribers with one site and subscribers with thousands, and they pay the same flat fee. Nobody gets punished for growing.

We set that price in 2010, while we were building towards launching in 2012. In the sixteen years since, there has been not one price increase. Not a single one. Not an inflation adjustment, not a tier restructure, not a quiet grandfathering of old customers onto worse terms.

That is over a period which included near-record inflation, and during which our own costs have roughly quadrupled. Recently the AI boom has pushed hardware prices up again, which we absorbed too.

I am not claiming that is good business practice. It is arguably terrible business practice. But it is the same principle running in the other direction: if I am going to tell you that a website is a living thing with a running cost, I should be willing to absorb a running cost of my own rather than repricing every time it pinches.

For context, I personally spend more on coffee in a month than a mySites.guru subscription costs. Our customers stay, on average, three to five years, which is roughly the interval between major CMS migrations. The two numbers match because that is what a retainer looks like when the thing being retained is alive.

So when I say sell the running cost, I am not asking you to do something I have avoided doing myself.

What to say instead

In practice that means writing a different first proposal. Nobody ever fixed this with a better closing technique.

Price the build and the running cost as one proposition, not a build with an optional extra bolted on at the end. A maintenance line that appears after the client has mentally signed off the project reads as an upsell, and it gets cut. A running cost that was in the first conversation reads as the cost of the thing.

Say what the money buys in terms of the thing they own, not in terms of your tasks. “Core and extension updates applied and tested monthly” is a description of your afternoon. “Your site stays on a version that still receives security patches” is a description of their asset.

And be specific about the milestone spikes, in advance. Every CMS has a major version transition every few years, and it will cost real money. A client told at the start that there is a significant project roughly every three or four years is a client who can plan for it. A client told about it for the first time when the version has already gone end of life is a client who feels ambushed, and reasonably so.

If you want the argument in one line: you are selling the running cost of something alive, not insurance against something going wrong.

How mySites.guru helps support you, to support your dying Joomla 3 end of life sites

None of the above helps the sites you already have on the books, so here is what we actually do for them. It is a holding position rather than a fix, and I would rather say that than sell it as something it is not.

One-click Joomla 3.10.999 core patches

We apply the community core patches across your whole portfolio of Joomla sites, with no eLTS licence needed. The one-click Joomla 3 patch tool replaces 65 core files and picked up four more CVEs over summer 2026, including an unrestricted SHTML upload and a com_contact access control flaw. Of the 13,341 Joomla 3 sites where we can currently read the core files, 10,512 have unpatched ones we could fix. That is 79% of the sites that could be safer today and are not, which is the single most fixable number in this entire post.

JoomShaper’s own Joomla 3 packages, deployed and revertible

We deploy them for Helix Ultimate, Helix3 and SP Page Builder, installed through Joomla’s native installer so the vendor’s own version gates run, which is the check that finds them, with a revert if you need it. That matters more than it sounds, because JoomShaper reused the same version string across two different patch releases, so no inventory tool can tell a patched site from an unpatched one by version number alone.

Every published core CVE, flagged per site

We flag each one against the site’s exact version, on the sites list and on the site itself, so an end-of-life core stops being an abstract worry and becomes a count you can show a client.

Every Joomla version tracked back to 1.5

That reach is intended. We support old versions so you can see and move them, not so you can leave them sitting there.

You can point the Joomla 3 end of life check at your portfolio of Joomla sites and have the list in a few minutes.

The uncomfortable part

The data in this post came from our own customers’ sites. These are, by definition, agencies and site owners who care enough to connect their sites to a monitoring platform and pay for it every month. This is the diligent end of the market.

And the diligent end of the market is running 30,305 end-of-life Joomla 3 sites, 20,671 of which are not even on the final release, with 22,195 known-vulnerable extensions between them.

Now scale that up. Joomla runs on millions of sites. Almost none of them are connected to anything like this. Nobody inventories their extensions, nobody tells their owner when a component goes critical, and nobody counts them when a number like 4.90% gets published. Whatever the real figure is out there, it is not better than the one measured on sites that are actively being looked after. It cannot be.

So, back to the question. You can bury your head in the sand, and plenty of people reading this will, because the alternative is a difficult conversation with a client who does not want to have it. That cost is real, and I am not going to wave it away.

We even built you the switches.

Those two badge toggles went in this week, and I mean them. If you already know a site is on Joomla 3, and the pills are just noise on a screen you look at forty times a day, turn them off. Nobody needs to be shouted at by their own dashboard.

Read the help text underneath them, though, because we wrote it carefully. Cosmetic only. The sites are still checked against published advisories, the has-core-vulnerabilities and has-vulnerable-plugins filters still find them, the left-menu counter still counts, and the alert emails still go out. Hiding the badge changes what you see, not what is true.

Which is the whole post in one settings page. You can turn off the warning. You cannot turn off the CVE.

Just be clear about what you are choosing. You are not deferring a technical task. You are holding a liability on someone else’s behalf, for free, until it goes off. And on current numbers it goes off about five times more often than it needs to.