Joomla site hacked: what to do

In the summer of 2026 a wave of mass, automated hacks swept across Joomla websites. These attacks are not manual and they don't pick their victims: bots crawl the internet, find a vulnerable extension and upload a web shell within seconds. If your site has suddenly started redirecting visitors to other pages, spewing spam or displaying a "Hacked by..." message, below is a step-by-step walkthrough of what to do right now and how to take back control.

How to tell your site has really been hacked

Sometimes a hack is obvious right away: someone else's message replaces your homepage. More often, though, it's quiet and runs for weeks, and you're the last to find out. Here are the signs that give an infection away:

• The site redirects visitors to unrelated pages (casinos, pharmacies, sketchy downloads), especially when they arrive from search or on a phone.
• Other people's pages or gibberish characters have appeared under your site in search results, and Google shows "This site may be hacked."
• Users with Super User rights that you never created have turned up in the admin area.
• Your host has sent a notice about malicious code or unusual load, sometimes along with an account suspension.
• The server is sending spam without your knowledge, and your mail IP has landed on RBL blacklists.
• Unfamiliar PHP files, files with a double extension (.xml.php) or odd letter case (.pHp) have appeared in the media, images or tmp folders.
• Organic traffic has dropped sharply: pages have fallen out of the index or been flagged as unsafe.

Even a single item on this list is reason enough for a full check. A hack often works selectively: to an ordinary visitor the site looks fine, and the redirect only fires for people arriving from Google, or just once per device. So "everything opens fine for me" doesn't yet mean "everything is clean."

Why Joomla is being hacked en masse in summer 2026

The problem almost never lies in the Joomla core itself, which is actually fairly well protected, but in popular third-party extensions. Over a short span, several critical vulnerabilities (CVSS up to 10.0) were disclosed at once, allowing unauthenticated upload and execution of PHP code. In other words, a full takeover of the site without any password:

• JCE (Joomla Content Editor): CVE-2026-48907, fixed in version 2.9.99.5.
• SP Page Builder: CVE-2026-48908, fixed in 6.6.2.
• iCagenda: CVE-2026-48939, fixed in 4.0.8 and 3.9.15.
• Page Builder CK: CVE-2026-56290, fixed in 3.6.0.

Some of these were exploited as 0-day, before a patch was even released, and all of them have been added to the CISA catalog of actively exploited vulnerabilities (KEV). The exploits are public, and the attacks are carried out by bots across the entire internet. So the argument "my site is small, who would want it" doesn't hold: the bots don't care about your traffic, they go after a single signal, whether a vulnerable extension is installed.

The scale is confirmed by national cybersecurity centers, too. On July 9, 2026, the Australian Cyber Security Centre (ACSC) warned of a large, ongoing global campaign: attackers are mass-scanning CMS-based sites and planting web shells, with Joomla JCE named directly in the list of vulnerable software. The ACSC notes that the campaign is likely being accelerated by AI, cutting the time from vulnerability disclosure to attack down to just a few hours.

One especially visible wave is the homepage defacements signed "Hacked by AntonKill." Joomla-focused sources tie it primarily to a vulnerability in the Helix3 template framework by JoomShaper (CVE-2026-49049): malicious code is injected straight into the template parameters in the database, so cleaning the files alone is sometimes not enough.

The first hour: what to do immediately

The goal of the first hour is not to "cure" the site but to stop the damage and preserve your ability to investigate calmly. In order:

1. Change the passwords. The Joomla administrator, your hosting and control panel access, FTP/SFTP and the database. If one password was reused in several places, change it everywhere.
2. Close the site to visitors. Put it into maintenance mode (offline in Joomla) or temporarily serve a placeholder. This protects visitors from redirects and malware and stops the spam being sent.
3. Preserve the evidence. Download the latest server logs (access and error) and make a full archive of the site and a database dump "as is," before any cleanup. The logs reveal both the timing and the method of the break-in.
4. Check the administrators. Block or delete Super User accounts you didn't create. While you're at it, check whether the email on your own account has been changed.
5. Notify your host. Many hosts help with initial diagnostics, grant access to their own scanners and, importantly, won't suspend the account if they see you're already dealing with the problem.
6. Find the last clean backup. Check whether you have a backup from before the infection. The path your recovery takes depends on this.

How to clean the site up properly

The main mistake sounds like this: "found one odd file, deleted it, felt reassured." A web shell is almost never alone: backup copies sit alongside it, and injected snippets hidden in the database and in legitimate files restore access. Cleanup is a system, not a single action.

1. Find and remove the web shells

Look for recent, suspicious PHP files where they shouldn't be: in images, media, tmp, cache. The tells: a double extension (.xml.php), non-standard letter case (.pHp), a recent modification date, and also PHP using the functions eval, base64_decode, gzinflate, assert, and preg_replace with the /e modifier. Such code is almost always malicious.

2. Compare files against a clean copy

The most reliable approach is to compare your site's files against a reference: download a clean Joomla of your version and the same extensions from official sources and diff them. Anything that differs in the core and in the extension files is a candidate for replacement. Keep your own changes (template, configuration) separate while doing this.

3. Clean the database

Check the database for injections: in template parameters (especially Helix3), in articles, in modules and in system plugins. Look for script and iframe tags, injected snippets with document.write and links to external domains. While you're at it, check the users table and the extensions table: that's where both hidden admins and malicious plugins that re-create shells are stashed.

4. Check the persistence points

Look into .htaccess (redirect rules and PHP wiring), the scheduled tasks (cron) and the Joomla system plugins that run on every page load. This is where a "second key" is most often left behind, so the attacker can come back after a cleanup.

Restoring from a backup: when it works

A backup is the fastest route, but only under two conditions: the copy was made demonstrably before the infection and you know exactly how they got in. If you restore the site and don't update the vulnerable extension, reinfection is a matter of hours.

The difficulty is that a hack is often noticed weeks later, and all the recent backups already contain the shell. Then you do have a clean copy, but it's too old: new articles, orders and settings have appeared since. In this case the best approach is to combine them: deploy the old clean copy as the base, carefully move the recent content over from the database (after checking it), and be sure to update everything they could have gotten in through.

And a separate word about the future: a backup is only as useful as it is real and tested. Backups should be created automatically, stored separately from the site (so ransomware or a defacement can't touch them) and at least occasionally deployed to a test environment to make sure they actually work.

How to close the hole so it doesn't happen again

Cleaning the site is only half the job. If you don't remove the cause, it will all repeat. The baseline security set:

• Update Joomla and all extensions on time. Most of the 2026 hacks aren't a "clever attack" but entry through an extension that already had a patch out. Delete whatever you don't use: every extra extension is an extra door.
• Enable two-factor authentication for admin accounts and get rid of obvious logins like admin.
• Set file and folder permissions correctly (usually 644 for files, 755 for folders) and forbid PHP execution in the upload folders (media, images), where it has no business running.
• Put the site behind Cloudflare or another WAF: it cuts off part of the automated attacks and scanners before they ever reach Joomla.
• Make automatic backups stored separately from the site, and test them.
• Remove development leftovers from the server: old copies, test scripts, forgotten phpMyAdmin installs and archives. Those are often exactly what becomes the way in.

When it's worth calling in a specialist

A lot of the above you can genuinely do yourself, especially if the hack was caught early and you have a recent clean backup. But there are situations where delay and half-measures cost more than getting help:

• The malware comes back after every cleanup: that means a hidden payload was missed or the original hole wasn't closed.
• There's no clean backup, and the site has live content and orders you can't afford to lose.
• The host has suspended the account or the site is flagged in Google as "unsafe," and you need to pass a re-review quickly.
• The defacement lives in the database (that same Helix3 and "AntonKill"), where cleaning the files isn't enough.
• The site is commercial, and every day of downtime means lost inquiries and rankings.

If that's your case, I recover hacked Joomla sites end to end: I find and remove the shells and redirects, clean the database, close the vulnerability, get the site back into search and set up protection so it doesn't happen again. More about the service and pricing on the page website recovery after a hack. I do the diagnostics for free, before any work begins.