Joomla Website Hacked? Recovery and Security Checklist

An unfamiliar message, a changed homepage or an unexpected redirect needs investigation. This is a recovery guide, not a demonstration of an attack. A name displayed by an intruder does not prove which vulnerability was used.

If your Joomla site may be compromised, protect visitors and preserve evidence before making changes. The checklist below covers files, database content, accounts and backups, followed by the information needed to request help.

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 a Joomla website can be compromisedhacked en masse in summer 2026

Possible entry points include an outdated extension, an unsupported Joomla installation, stolen credentials or unsafe hosting configuration. The page displayed after an attack does not establish which of these happened.

Inventory the installed Joomla, PHP, template and extension versions. Compare them with the vendors' current security notices and supported releases. Do not select an update or a recovery procedure solely from a nickname shown on the damaged page.

Record the relevant versions, timestamps and log entries. This gives the investigation a testable starting point and helps separate a software vulnerability from compromised access.

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 unwanted content returns after files have been restored, so database settings and other persistence points also need investigation.
• 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.