Is Joomla 3 still safe to run if I keep it updated to 3.10.12?

3.10.12 was the last version the Joomla project itself released, and updating to it does not add any protection against vulnerabilities disclosed since August 2023. It is the same as running any other end-of-life release: no further official fixes are coming.

What is Joomla's ELTS programme?

Extended Long Term Support, a separate paid programme run by the Joomla project that backports some fixes to end-of-life versions. It is not the same as active support, and it does not cover every issue the community has found.

How urgent is migrating off Joomla 3, realistically?

It should be treated as an active, ongoing project rather than a someday task. Every month that passes adds more disclosed, unpatched core vulnerabilities to the pile, and the PHP versions Joomla 3 depends on are being dropped by hosting providers on their own timeline, not yours.

Joomla 3 Is End Of Life

What this check and mySites.guru tool looks at on your site

This check identifies any connected site still running the Joomla 3.x series. Joomla 3 reached end of life in August 2023, when the Joomla project stopped releasing security updates for it.

Unpatched by design, and getting worse

End of life doesn’t mean old, it means unpatched by design. Every core Joomla vulnerability disclosed since August 2023, and there has been a steady stream of them, cross-site scripting, access control issues, hardening around SQL injection and file uploads, gets fixed within days in whichever Joomla series is currently supported. The identical flaw in Joomla 3 core stays open indefinitely, because there is no supported version left to fix it in, and it stays open whether or not anyone announces it loudly: a fix landing quietly in a Joomla 6 point release is also, implicitly, a disclosure of a bug that has existed in the shared codebase since long before Joomla 3 stopped being maintained.

The Joomla project runs a separate, paid Extended Long Term Support (ELTS) programme that backports some of these fixes to Joomla 3, and the wider community, including independent researchers and site operators comparing notes, has found and backported others outside that programme entirely. Both are useful, and both are also partial: they narrow the gap rather than closing it, cover a subset of what gets disclosed rather than everything, and neither is the same as running a version the core project is actively maintaining as its main line of development.

There’s a second, quieter problem sitting underneath the security one. Joomla 3 requires an old PHP branch to run, and hosting providers are steadily dropping support for those PHP versions regardless of what happens with Joomla itself. That means a Joomla 3 site isn’t just accumulating unpatched vulnerabilities with each month that passes, it’s also on a collision course with its own hosting environment. Migration stops being optional once the host removes the PHP version the site depends on; the only choice is whether it happens on your schedule or on theirs.

A currently supported major version

The site is running a currently supported Joomla major version, not 3.x. If migration isn’t possible immediately, the specific patches available for vulnerabilities disclosed since Joomla 3 went end of life are applied and kept current, so end-of-life status is being actively managed down rather than left as a fact nobody revisits.

It’s worth being honest about why sites stay on Joomla 3 for years rather than migrating promptly, because it’s rarely neglect. A Joomla 3 to Joomla 4 or later migration is not a version bump, it’s closer to a rebuild: templates, extensions and custom code written against the old framework often don’t carry across cleanly, and testing everything that depends on them takes real budget and real time. For an agency managing someone else’s site, that’s a conversation about cost that the client has to agree to, and that conversation doesn’t always happen quickly. None of that makes the risk smaller in the meantime, which is exactly why the interim patching step matters: it’s the difference between an unpatched site and a managed one while the larger migration gets planned and paid for.

How to fix it

Plan and run the migration to a supported Joomla version. This is the actual fix; everything else here buys time, it doesn’t replace it.
If migration is going to take a while, don’t leave the site on stock 3.10.12 in the meantime. Apply the community and ELTS-derived patches for the vulnerabilities disclosed since end of life.
Read how to prevent accidental Joomla version jumps before you start the migration itself, so an update-channel setting doesn’t jump the site past the version you’re actually ready for.
While a site is still on Joomla 3, also check whether FTP layer credentials were left behind in configuration.php from the original install.

There is also a well-known free, community-run reference for this, the “3.10.999” project on GitHub, which documents the recommended patches for keeping a Joomla 3 site minimally secure past end of life. It’s worth knowing this exists, but it’s a manual reference repository you compare against and apply yourself, file by file, rather than an automated fix, and it was never intended to be complete or to track new disclosures as a matter of course.

What mySites.guru does about it

mySites.guru flags every connected site still on Joomla 3, and includes a one-click patch tool that fixes every known Joomla 3 security issue disclosed since 3.10.12, the last version the project itself released. It works by tracking the expected file hash for each patched file: flip the toggle on and it replaces anything that doesn’t match, across every connected Joomla 3 site at once, no separate ELTS subscription required and no need to apply anything file by file yourself. See end-of-life version support in mySites.guru for how this is tracked across every Joomla and WordPress release, not just Joomla 3.