Your options for a Joomla 3 site, and the deadline that picks one for you
Joomla 3 reached end of life on 17 August 2023, and the paid eLTS programme that patched it closed on 17 February 2025. A Joomla 3 site now has three possible futures: patched and held while a move is planned, migrated to a supported Joomla, or switched off. This page sets out what each one involves, why the forks and rescue projects are not a fourth option, and why the date is usually set by your host rather than by you.
Measured across sites connected to mySites.guru, 28 August 2026. These are managed sites, so they are the good end of the Joomla 3 population.
Stay and patch: a holding position
Most Joomla 3 sites cannot move this quarter. Patching closes the published holes while the move is planned and paid for, though the site stays unsupported.
Fixes are still available at three layers of a Joomla 3 site, and each covers different ground. Skip one and the other two leave a gap an attacker can use.
The core
Joomla stopped public releases at 3.10.12 on 8 July 2023. Advisories that reach back into 3.x have kept coming since, and Joomla now fixes them only in the supported branches. The community 3.10.999 project backports those fixes to 3.10.12, and mySites.guru applies the same backport with one click: 85 core files changed, 39 published advisories closed, and a switch back to stock 3.10.12 if you need it. The full list is on the core vulnerabilities page.
The patch needs 3.10.12 or a later 3.x build, and the PHP zip extension on the server, and 68.2% of the Joomla 3 sites in the mySites.guru dataset are behind 3.10.12. For those sites the first job is a backed-up update to the final public release, and only then the patch.
The extensions
These sites mostly get broken into through their extensions rather than the core, and whether yours can still be fixed depends entirely on its vendor. Some kept shipping Joomla 3 builds long after they said they would stop, some stopped and meant it, and some never said anything at all. The vendor tracker lists every statement we could find, with its source and the date we last checked it.
At the time of writing the vendors we record as still shipping Joomla 3 fixes are JoomlaWorks, Joomlatools, SEBLOD, Digital Peak, Tassos, VirtueMart, Web357, HikaShop and RSJoomla. JoomShaper is the awkward case: it announced no more Joomla 3 security patches on 9 July 2026, then shipped Joomla 3 packages for Helix Ultimate, Helix3 and SP Page Builder anyway. Those packages install only onto specific versions, and once applied they leave the version number unchanged, so a patched site and an unpatched one look identical to any updater. mySites.guru reads the files to tell them apart, as explained on how mySites.guru helps.
The server
The highest PHP version Joomla 3 was ever made to run on is PHP 8.1, and PHP 8.1 itself reached end of life on 31 December 2025. So a fully patched Joomla 3 site still runs on a language runtime that receives nothing, and no setting in a hosting panel changes that. That part of the holding position cannot be patched, and it sets the deadline covered below.
Why it is a holding position
Patching closes the holes someone has already found and published. It does nothing about the next advisory until someone backports it, nothing about an extension whose vendor has gone, and nothing about the PHP ceiling. A Joomla 3 site with every available patch is safer than it was, and still unsupported. Use the time it buys to plan the move.
See which of your Joomla 3 sites can be patched today
Connect one site and mySites.guru audits it free, with no card and no time limit. You see whether it is on 3.10.12, how many of the 39 core advisories are still open on it, and which of its extensions have known holes.
Rescue projects, and why none of them is a plan
Every end-of-life platform attracts projects promising to keep it alive. Joomla 3 has several, and they are not equal.
The 3rd party projects attempting to keep Joomla 3 alive:
Joomla 3.10.999 our own backport of the core security patches.
Patches the core, and nothing else. We call it a holding position rather than a fix, which is the honest description of every project on this list.
TLWebdesign the same patches, packaged as an installable extension.
Tom van der Laan took our patches and made them installable. That packaging is useful and he was still pushing to the repository in July 2026. Joomla's own security team declines to endorse it, in as many words.
joomlaworks/joomla-3.x continued 3.x development for code security and modern PHP.
Real engineering, but it forks the core. Nothing in it touches the extensions that are actually getting these sites hacked.
Joomla 3.x UTD a fork that keeps the Joomla name and numbers its releases 3.11, 3.13, 3.15.
Those versions never existed. Joomla's updater, the vulnerability databases, hosting scanners and our own inventory cannot interpret them, so no one can tell you whether that site is patched or not.
joomla-update.ch a vibe-coded patcher.
An AI-slop approach to somebody else's security. Generating patches for a codebase you have not read, for a CMS whose maintainers have stopped issuing fixes, then offering them to strangers to run on production sites, produces plausible-looking output and calls it a security process.
The PHP 8 compatibility work getting a Joomla 3 codebase to run on PHP 8.
The most useful of the group and the most likely to be misread. It solves the hosting deadline in the next section. It does not make the site secure. Two different deadlines, arriving together.
Security patching is the one job where the code has to be right rather than convincing, and where the failure mode is silent. If you would not let an unreviewed model commit directly to a client's site, do not let one do it through a download page either.
The useful ones are careful work. Even so, the same three structural problems apply to all of them, which is why a fork or a patcher can buy time and still leaves a migration to do.
Extensions are what is getting these sites hacked
In the mySites.guru dataset, the damage on Joomla 3 sites is coming through extensions such as YOOtheme Installer, SP Page Builder and JCE. No core fork touches any of them. That is why we describe our own core patch as a holding position: a patched core under an abandoned template makes a safer site that is still unsupported.
Invented version numbers blind every tool that could warn you
Joomla 3 ended at 3.10.12. A fork that calls its releases 3.11, 3.13 or 3.15 emits a version string nothing else can interpret. Joomla's own updater cannot reason about it. Vulnerability databases key their affected ranges on real Joomla releases, and WAF rules and hosting scanners do the same. So does mySites.guru: a site reporting a version that never existed is a site no one can call safe or unsafe with any confidence. JoomShaper reusing one version string across two different security packages caused exactly this on a smaller scale. A fork that invents version numbers has the same problem permanently.
Keeping the Joomla name hides what the site runs
A fork that keeps the Joomla name and branding while shipping code the Joomla project did not write leaves the client, the host and the next developer unable to tell what they are looking at. "We are on Joomla 3.15" sounds reassuring and means nothing, because there is no such release.
The PHP 8 compatibility work is the most useful of the group and the most often misread. Getting a Joomla 3 codebase to run on PHP 8 solves the hosting deadline in the next section, which is a real and urgent problem, and leaves security exactly where it was.
The PHP deadline your host sets
This turns a deferred decision into an emergency, and Joomla has no say in it.
Joomla 3 needs an old PHP branch. Hosting providers are removing those branches on their own schedule, and they do not ask first. When a host drops PHP 7, a Joomla 3 site that has not been made PHP 8 compatible simply stops working.
On some hosts the change is a one-way door. Fasthosts is the example we keep running into: a customer switches a site to PHP 8 to see whether it works, finds it does not, and then discovers there is no route back to PHP 7. The test becomes the migration, with no undo. The cautious thing an administrator does, trying it to see, is the action that takes the site down.
So the real choice is between migrating on a date you pick, with a staging copy, a rollback plan and a budget agreed in advance, and migrating on the date your host picks, at whatever hour it picks, with the client on the phone. Migrating later was never one of the options.
The host is right to do it. PHP 7 left security support years ago, and a host still serving it is running an unpatched runtime underneath every customer on the server, including the ones who did everything right. A host that never forces PHP upgrades is neglecting all of them, and that is a reason to leave.
Even a site that has had the PHP 8 work done reaches its ceiling at PHP 8.1, which has been end of life since 31 December 2025. Selecting PHP 8.2 or later in the control panel breaks the site. mySites.guru shows the PHP version every connected site is serving, with a green, amber or red badge for how current its patch level is, so across a list of Joomla 3 sites you can see which ones are closest to the edge.
Is a Joomla 3 site hacked right now?
We clean it for a single fixed fee of £120 per incident, usually the same day. We screen it before you pay, so in the rare case it cannot be fixed you are not charged, and non-subscribers get a free month of mySites.guru with it. Get it fixed
Migrate to a supported Joomla
Migration is the only real fix. It is also closer to a rebuild than an upgrade, so price and plan it as one.
There is no button that turns a Joomla 3 site into a Joomla 5 or 6 site. Joomla calls the move from 3.10 to 4 a mini-migration, and every template, component, module and plugin on the site needs a version compatible with the target release. Some will not have one. The common blockers are a template framework with no modern successor, a page builder whose content has to be rebuilt, and a bespoke extension written for a client a decade ago. Sometimes the only way to find out is to attempt the move on a copy and fix what breaks.
Aim at Joomla 6 unless something stops you. Joomla 4 left security support in October 2025, so it is no longer a destination. Joomla 5 leaves regular bug-fix support on 13 October 2026 and gets security fixes only until October 2027. Moving a site to Joomla 5 now buys about a year before the same conversation starts again.
Agencies that migrated once still have the problem, and the mySites.guru dataset shows why. Half of Joomla 4 sites run at least one extension with a known vulnerability, the widest spread of any branch we measure, against 22.3% of Joomla 3 sites. The version number was never the risk. The risk is whether anyone keeps watching the site after the move, so build the running cost into the migration quote rather than adding it afterwards.
What mySites.guru does and does not do for a migration
mySites.guru does not migrate sites. Its mass upgrade tool follows the update path each site reports, exactly as Joomla's own update page would, and the Joomla 3 to 4 jump is not an update path. We also do not offer a fixed-fee migration service, because every Joomla 3 site is different and there is no way to quote a fair price for one before someone has opened it up.
It does make the move plannable. Before you start, the extension inventory shows what every site actually runs, so you can see which sites share a template or a page builder and plan them as a batch. During the move, keep monitoring the old site until it is switched off. Afterwards, the connector has to be swapped, because the Joomla 3 connector will not run on Joomla 4 or later:
- Remove the mySites.guru plugin from the Joomla 3 site before migrating.
- Delete the old site entry from your mySites.guru account.
- Migrate the site to Joomla 4, 5 or 6 and get it stable.
- Add the site to mySites.guru again, choosing the connector for Joomla 4 and later, and install it in the migrated site.
The full walk-through, with Joomla's own migration guides, is in migrating to Joomla 4 or later when using mySites.guru.
Which option fits your site
Most portfolios need more than one of these at once. Sort each site by what it runs and where it is hosted. Its age is a poor guide.
- Patch and hold
- The site is on 3.10.12, its host still offers PHP 8.1 or older, and the migration has a date but no budget yet. Apply the core patch, the JoomShaper packages and every vendor fix that still ships, and treat the result as cover measured in months.
- Update within 3.x, then patch
- The site is older than 3.10.12. The core patch only installs on 3.10.12 or later, so the first job is a backed-up update to the final public release, then the patch.
- Migrate now
- Your host has announced the end of PHP 7, the site runs a page builder or template whose vendor has stopped, or the site takes payments or personal data. Every one of those makes the holding position too thin.
- Rebuild rather than migrate
- The template and the main extensions have no Joomla 5 or 6 successor. A move like that is a new site with the old content imported, so quote it as one.
- Retire it
- No one can say who the site is for any more. An unmaintained Joomla 3 site on a client's domain is a liability with their name on it, and switching it off is a legitimate option.
Read the detail
The posts this page draws on, on the mySites.guru blog.
- Joomla 3 Didn't Fail. Your Retainer Did.
Joomla 3 sites are five times more likely to be hacked than Joomla 6, and the agencies who migrated are doing worse.
- Fix Joomla 3 Security Issues in One Click
Patch every known Joomla 3 security vulnerability across all your sites with a single toggle in mySites.guru - no manual file edits, no eLTS subscription.
- The One-Click Way to Patch JoomShaper Extensions on Joomla 3
mySites.guru backports JoomShaper's security fixes into SP Page Builder, Helix3 and Helix Ultimate on Joomla 3, across every site in your account.
- The Joomla 3.10.999 Project
The Joomla 3.10.999 project backported critical security patches to end-of-life Joomla 3 sites. What it was, why it existed, and what to do now.
- Migrating to Modern Joomla When Using mySites.guru
How to keep your sites connected to mySites.guru when migrating from Joomla 3 to Joomla 4, 5, or 6. Step-by-step connector swap process.
- Why PHP 8.5.7 Shows Amber When PHP 8.4.24 Shows Green
PHP 8.5.7 shows amber while 8.4.24 shows green because the badge checks whether you are on the newest patch in your branch, not which branch you picked.
Keeping Joomla 3 patched is part of the subscription
The one-click core patch, JoomShaper's Joomla 3 packages, vulnerable extension alerts and malware scanning are all included, alongside everything else mySites.guru does for Joomla and WordPress. No per-site fees, and no price increases since 2012.
Keep your Joomla 3 sites patched while you plan the move
One free audit of one site, no card and no time limit. See what is still open on it before you decide what to do with it.