Attackers now use AI to turn published vulnerabilities into working exploits faster, which makes any website running outdated software easier to compromise. As of November 2026, Joomla 3 and 4 and PHP 8.1 and older receive no security fixes, PHP 8.2 loses them on 31 December, and WordPress officially supports only its latest release.
AI did not make your website vulnerable
A website can look healthy and still be the easiest target on its server. It loads quickly, and nothing has visibly gone wrong in years. Underneath, it may be an outdated WordPress or Joomla install: a release that stopped receiving fixes in 2023, on a PHP version that went out of support last December, with a plugin or two whose authors walked away long ago.
None of that is new. What changed in 2026 is how little it costs to find those weaknesses and use them. Attackers have long had scanners that sweep the internet for known flaws. They now also have AI models that help turn a published vulnerability into a working exploit in less time, and with less skill, than it used to take. AI did not make your website vulnerable. It made the outdated software underneath it cheaper to attack, for every attacker at once.
This is also why “we are too small to be a target” no longer holds. Nobody picks a small site out by name. A scanner reads the version number, and a vulnerable version number is the only qualification an attacker is looking for.
What this year’s evidence shows, and what it does not
Two reports from 2026 cover the two ends of the problem. The first came from the Google Threat Intelligence Group on 11 May. Its AI threat tracker opens with this: “For the first time, GTIG has identified a threat actor using a zero-day exploit that we believe was developed with AI.” A criminal actor had built a script that bypasses two-factor authentication in a popular open-source server administration tool and planned to use it in a mass exploitation event, which Google says its discovery may have prevented.
A quieter detail in the same report matters more to an ordinary website. Google observed a state-backed group it tracks as APT45 sending thousands of repetitive prompts to an AI model, working through published CVEs and validating proof-of-concept exploits for them. What that describes is a production line whose raw material is vulnerabilities that already have a public write-up, and whose market is every site that has not yet installed the fix.
The second report shows the receiving end. In July the Australian Signals Directorate’s cyber security centre issued a critical alert about a large-scale campaign against website content management systems. It named 17 products. Thirteen were WordPress plugins, including Ninja Forms, Gravity Forms, WPvivid Backup and the Breeze cache plugin. The other four were Craft CMS, MaxSite CMS, MetInfo and JCE, the editor extension found on a large share of Joomla sites. Many small and medium-sized businesses were among those hit.
The method barely varied. A scanner finds a site running a vulnerable version, and the exploit that follows leaves behind a web shell, a small file that lets the attacker run commands on the server whenever they choose. It is mostly used quietly, to capture what visitors type into your forms or to serve scam pages under your domain. The flaws on the list were known ones, the kind normally closed by installing an update, so nobody running the campaign had to discover anything.
It would be dishonest to stitch the two reports into a single story. Nothing published proves that a model wrote the tooling behind the July campaign, and Google’s zero-day was aimed at a server administration tool, not at a CMS. Read side by side, though, they say something uncomfortable. The weaknesses being used are old and well documented, while the tooling pointed at them keeps getting faster and cheaper to build.
Still working is not the same as still supported
WordPress and Joomla are not the problem. Both are actively developed, and a current install of either is a sound thing to run a business on. The trouble starts when an install stops being maintained, and “maintained” comes with dates.
WordPress, Joomla and PHP support dates, November 2026
| Software | Where it stands |
|---|---|
| Joomla 3 | End of life since 17 August 2023 |
| Joomla 4 | End of life since 14 October 2025 |
| Joomla 5 | Security fixes only, until 12 October 2027 |
| Joomla 6 | Current release |
| WordPress | Only the latest major release, 7.1, is officially supported |
| PHP 7.4 and 8.0 | End of life since 2022 and 2023 |
| PHP 8.1 | End of life since 31 December 2025 |
| PHP 8.2 | Security fixes only, ending 31 December 2026 |
| PHP 8.3 | Security fixes only, until 31 December 2027 |
| PHP 8.4 and 8.5 | Actively supported |
The Joomla and PHP dates come from each project’s own schedule (Joomla, PHP). WordPress works differently. Its supported versions page says the only officially supported version is the latest major release, and that security fixes reach older branches “as a courtesy”, with no guarantee and no timeframe.
Two rows deserve a second look. If your site is on PHP 8.2, its security support ends on 31 December, a few weeks from now. And WordPress will still install on PHP 7.4, which is how a fully updated WordPress site can be sitting on a PHP version that has had no security fixes for four years.
The table also leaves out the part that produced most of the Australian list: plugins, extensions and themes. They have no published end-of-life date. A plugin is abandoned when its author stops shipping updates, and the only notice you get is a “last updated” line that keeps getting older. Paid themes and extensions add a second trap, because when the licence lapses the updates stop arriving even though the product is still maintained.
Why your host cannot patch this for you
We have written before about where a host’s job ends and yours begins. Outdated application code sits on your side of that line. It is worth being exact about why, because hosting companies, ours included, sell security features that are easy to mistake for a cure.
A web application firewall blocks requests that match known attack patterns. That stops a large amount of automated traffic, but the vulnerable code is still there behind it, and a request the rules do not recognise goes straight through. Producing variations on a known exploit is exactly the kind of work that has become cheap.
Malware scanning works after the fact. It finds files it recognises as malicious, yet it cannot tell you what was copied before the file was caught or whether a second way in was left somewhere else. Backups have a similar blind spot. If a web shell was planted three weeks ago, every backup since then contains it, and restoring the most recent one restores the attacker too (we covered how to test a restore in our piece on backup policies). As for the padlock, an SSL certificate encrypts the connection to your application and says nothing about whether that application can be trusted.
Those layers still earn their place, because they turn away a great deal of opportunistic traffic and buy time when something new appears. What they cannot do is make software nobody maintains safe to leave online.
What an incident costs
The visible damage is usually the smaller part. A hacked site that serves malware or phishing pages gets flagged by browsers and search engines, and the warning page in front of your domain keeps costing you visitors after the files are clean. Cleanup is rarely a matter of deleting one file. Someone has to work out how the attacker got in and replace every password and key the site held before rebuilding from a copy that can be trusted. If personal data was exposed, the GDPR may also require you to notify your supervisory authority within 72 hours of finding out (what that regulation asks of a host is in our GDPR hosting guide).
A planned upgrade comes with a quote and a date. An incident has neither, and it arrives on the attacker’s schedule. Security debt does not go away because the site still loads; it waits until someone chooses to deal with it or an incident makes the choice for them.
How to secure an outdated WordPress or Joomla site this week
No single product or setting removes this risk. The seven steps below are in the order we would do them.
1. Write down what the site runs
You cannot manage software you do not know you have. In WordPress, open Tools, then Site Health, then the Info tab, which lists the WordPress version, the PHP version and every plugin and theme. In Joomla the same details are under System, in System Information. In cPanel, MultiPHP Manager shows the PHP version for each domain. Add anything custom to the list, including old scripts in forgotten folders and the subdomain someone set up for a campaign in 2019.
2. Move to supported versions
Start with PHP, because it is the quickest win. On cPanel the change is a dropdown in MultiPHP Manager and takes effect in seconds; our PHP upgrade guide covers the compatibility checks to run first. Then bring the CMS itself up to date. For WordPress that is normally an update. For Joomla 3 or 4 it is a migration, so give it a plan and a date instead of an afternoon.
3. Switch on automatic updates
The Australian guidance recommends automatic security updates wherever they are practical. The reason is timing: the window between a fix being published and an exploit circulating keeps shrinking, and a person who checks for updates once a month no longer fits inside it. If you are nervous about an update breaking the site, try it on a staging copy first.
4. Delete what you do not use
A deactivated plugin is still a set of files on the server, and a vulnerable file can often be reached whether or not the plugin is switched on. Delete what you do not need. Then look at the “last updated” date on everything that remains, and find a replacement for anything that has gone a year or more without a release.
5. Tighten the admin logins
Give every CMS administrator a unique password and two-factor authentication, and protect the hosting account behind the site the same way (our 2FA guide covers the client area and cPanel). While you are in the user list, remove accounts for people who have left. An admin account nobody remembers creating is worth investigating on its own. The rest of the WordPress side is in our Securing WordPress guide.
6. Keep a backup you have actually restored
Offsite backups matter only if they restore, and after a compromise they matter only if you can tell which one is clean. Run a test restore now, while nothing is wrong, and note how far back your retention goes. That number is the longest an intruder can sit unnoticed before every copy you hold includes them.
7. Treat odd behaviour as an incident
New admin accounts, changed core files, unfamiliar scheduled tasks, redirects that only some visitors see: each of these deserves a proper look. If you do find a web shell, the Australian advice is to treat the whole server as compromised. Updating the CMS at that point closes the hole the attacker came through and leaves them inside, so the account needs isolating and its credentials replacing before the site is rebuilt from a source you trust.
When an update is not enough
Some sites cannot be brought up to date with a few clicks. A Joomla 3 site may depend on extensions that never made the jump to version 4, and bespoke PHP written for version 5.6 will often not run on 8.4 without real development work. Heavily customised WordPress installs end up in the same place when years of custom code are wound through an abandoned theme.
Postponing is not a strategy in these cases, but there is more than one way forward. Sometimes the answer is an upgrade with a handful of extensions swapped for maintained ones. A site that is mostly information, with no logins and no orders, can often move to a much simpler setup that has no database or admin panel to attack at all. We documented one move off long-abandoned software from start to finish, a vBulletin 3 forum taken to Discourse, in this step-by-step guide. None of this is an argument for chasing whatever is newest. The aim is a site where every part still has someone shipping fixes for it.
How GOZEN HOST handles its half
On our shared and WordPress plans every account is isolated with CloudLinux, sits behind a web application firewall and is scanned for malware (Imunify360 or cPGuard, depending on the server). Backups are taken daily and stored offsite, with a restore you can run yourself. WordPress core and plugin updates can be set to automatic per site, and we recommend it. The details are on the WordPress hosting and security pages.
Our PHP selector runs from 7.4 to 8.5. The old versions are there so that a legacy application has somewhere to run while it is being fixed, and we would rather nobody treated them as a permanent address. Which version your site uses is your setting to change.
What we will not claim is that any of this makes an abandoned application safe. If you are thinking of moving, migration is free, and our team can look at what the site runs and tell you whether it needs more than a change of server. One limit is worth stating up front. A migration is not a cleanup: a site that is already compromised has to be assessed and cleaned first, because copying it to a new server copies the attacker’s files along with yours. We would much rather have that conversation before an incident than after one.
Frequently asked questions
Can AI hack my website?
Not by itself, and not any site at will. AI helps attackers do familiar work faster, mainly turning published vulnerability reports into working exploit code and finding the sites that still run an affected version. In May 2026 Google’s threat intelligence team reported the first zero-day exploit it believes was developed with AI. Sites on outdated software are the ones that speed-up hurts most.
Is an outdated WordPress site a security risk?
Yes. WordPress officially supports only its latest major release, and every plugin and theme carries its own published flaws. A July 2026 alert from Australia’s cyber security centre named 13 WordPress plugins being exploited through known vulnerabilities. An out-of-date site stays exposed to each of those it has installed until it is updated.
Is Joomla 3 still safe to use?
No. Joomla 3 reached end of life on 17 August 2023 and Joomla 4 on 14 October 2025, so neither gets free security fixes from the project. Joomla 5 receives security fixes until October 2027 and Joomla 6 is the current release. Leaving Joomla 3 is a migration with its own compatibility work, so it needs a plan.
Which PHP versions are still supported?
As of November 2026, PHP 8.4 and 8.5 are in active support. PHP 8.3 receives security fixes until 31 December 2027, and PHP 8.2 until 31 December 2026. PHP 8.1 and everything older is end of life and gets no security fixes from the PHP project.
Will a web application firewall protect an outdated site?
Partly. A firewall blocks requests that match known attack patterns, which stops a lot of automated traffic. It does not repair the vulnerable code behind it, and a request the rules do not recognise still gets through. Treat it as a layer that buys time to update, not as a substitute for updating.
The short version
AI has changed the economics of attacking websites more than the methods. The flaws being exploited are mostly old ones with fixes already published, and the work of turning them into attacks keeps getting faster. A site on supported software, with automatic updates on and its unused plugins deleted, is a poor target for that kind of campaign. A site that has been left alone because it still works is the kind the scanners are built to find.
If yours can no longer be kept current, plan the replacement now, while the timing is still yours to choose. And if you are not sure what you are running, ask us. Send the CMS and PHP versions and we will tell you what is out of support.
Sources: Google Threat Intelligence Group, GTIG AI Threat Tracker, 11 May 2026. Australian Signals Directorate’s ACSC, Large-scale exploitation campaign targeting website content management systems, July 2026. WordPress supported versions. PHP supported versions. Joomla roadmap.
Not sure what your site is running?
Send us the CMS and PHP version. We will tell you what is out of support and whether it can be updated in place or needs a planned move. Migration to our platform is free.
Andreas writes about hosting infrastructure, performance, and migrations at GOZEN HOST LLC, a Top 25 WordPress Hosting Provider for 2026 (HostAdvice).
