How to Repair a Hacked Joomla Website in 2026

To repair a hacked Joomla website you must do two jobs, in order: remove the attacker’s persistence (files, database rows, rogue users, extra JCE profiles, .htaccess redirects), then close the hole they used (outdated core or a vulnerable extension). Patching alone leaves webshells. Cleaning alone gets you reinfected overnight.

Most guides still tell you to “scan with Sucuri, delete junk PHP, update Joomla 4.” That was incomplete in 2023. In August 2026 it is dangerous. Joomla 5.4.8 and 6.1.3 shipped on 18 August 2026 with core security fixes. JCE’s CVE-2026-48907 is on CISA’s Known Exploited Vulnerabilities list. Unpublishing a component does not remove its PHP. Overwriting a Joomla 3 tree with a Joomla 6 zip will not “clean” the site. It will break it.

This is the cleanup sequence we use at Infyways when a live Joomla shop, membership site, or brochure site is already serving malware. It is written for Joomla 4, 5, and 6. It is not a how-to-hack article. If you need hands-on help, use Joomla support and maintenance after you have a forensic copy of the infected files.

What you will learn

• How to tell a real compromise from a slow host or a plugin conflict
• The 2026 entry points other articles skip (JCE profiles, VEL, core CVEs fixed 18 August 2026)
• A step-by-step repair that does not destroy logs or restore an infected backup
• How Google Safe Browsing, Search Console, and “request a review” actually differ

What most Joomla malware guides get wrong

Advice you keep seeing	What actually happens
Run an online scanner, then go live	External scanners miss PHP webshells that never render to Googlebot
Update Joomla and you are done	The backdoor is still in /images, a template override, or a rogue Super User
Unpublish the vulnerable extension	The files still execute if the attacker hits the old URL. Official Joomla docs say uninstall, do not merely unpublish
Restore last night’s Akeeba backup	If the backup ran after the hack, you restore the malware
Upload the newest Joomla zip over the site	Wrong major version bricks the CMS. Match the installed major, then upgrade on a clean tree
Only scan PHP for eval and base64	Spam and redirects often live in JavaScript, .htaccess, modules, and article HTML

Joomla’s own checklist is still the baseline: treat the incident as a full compromise, check the Vulnerable Extensions List, and do not confuse a core refresh with a same-series repair. See You have been hacked or defaced and why unpublishing is not enough.

How to know a Joomla site is actually hacked

You do not need a dramatic defacement. In 2026 the quiet infections are the ones that kill SEO: hidden spam, Japanese or pharma links in modules, redirects for Googlebot only, or a new Super User that never logs in from your country.

• Google Search Console Security issues, or a Safe Browsing interstitial
• Host ticket: “malware detected, site suspended”
• Users you did not create, especially Super Users with a fresh registerDate
• Pages or .htaccess rules you did not write
• PHP files under /images, /media, /tmp, or a template folder that should only hold CSS and index.php
• JCE Editor profiles you never created (relevant if JCE is installed)
• Scheduled tasks or cron jobs you did not add
• Outbound spam from the site’s mailer

What scanners miss: VirusTotal and Sucuri SiteCheck are useful for “is Google already angry?” They are not a file integrity check. We still open JavaScript by hand. Automated tools love base64 and skip a one-line redirect in a minified JS file the template loads on every page.

Confirm Google’s view with the Safe Browsing site status tool and Search Console. Those are different queues from Bing or Norton Safe Web. Clearing one does not clear the others.

August 2026: what is actually being used against Joomla

Do not hunt for a mythical “Joomla is insecure” story. Hunt the hole that matches your stack.

Joomla core. On 18 August 2026 the project published security releases covering Joomla 5.4.7 / 6.1.2 and earlier in those lines, including CVE-2026-73337 (authentication bypass, moderate) and related access-control and upload issues. Current patched lines at the time of writing: 5.4.8 and 6.1.3. If you cleaned a site last week and left it on 6.1.2, you are not finished.

JCE (Joomla Content Editor). CVE-2026-48907 is actively exploited and listed by CISA. A vulnerable JCE is not “an overdue update.” Treat it as possible compromise: unexpected editor profiles, unexpected PHP in upload paths, then update to a patched JCE release (vendor guidance starts at 2.9.99.5, with 2.9.99.6 described as further hardening). Do not paste exploit URLs into production to “test.”

Everything else. Check VEL for every installed component, including page builders. For the broader 2026 picture, read our Joomla security 2026 guide.

Step 1: Freeze evidence before you delete anything

Take a full copy of files and the database as they are. Label it infected. Do not restore it later as “the clean site.” You need it to diff, to recover a unique article, and if you ever have to explain the incident.

Also copy web server access and error logs for the last 14 to 30 days. Once you start deleting PHP, you lose the URL that proved the entry point.

Step 2: Take the public site down without wiping the server

Use Joomla’s offline mode if the administrator still works. If it does not, a host-level placeholder is fine. Do not reformat the VPS yet. Do not disable logging. You are stopping visitors from hitting malware, not destroying the crime scene.

If you are on shared hosting, ask the host whether other accounts on the same user were writable. A cleaned Joomla next to an infected WordPress install will not stay clean.

Step 3: Name the infection type

Cleanup is different for each. Mixing them is why sites “get hacked again” in 48 hours.

• Webshell / backdoor: PHP in the wrong folder, extra Super User, odd JCE profile
• SEO spam: hidden links in modules, articles, or template overrides, often still ranking in Google
• Redirect: .htaccess, index.php in the template, or JS that only fires for certain user agents
• Mailer abuse: spam sent as the site, often a rogue user plus a form or cron

You can have all four at once. Fix persistence first, then content spam, then Google.

Step 4: Find the door they used

List every extension and template. Check VEL. Note Joomla version versus 5.4.8 / 6.1.3. If JCE is present, inspect editor profiles for anything you did not create. Search logs for administrator logins from unknown IPs and for component query strings you do not recognize.

Common 2026 doors: outdated JCE, outdated page builders, leftover Joomla 3 extensions on a “mostly upgraded” site, reused Super User passwords, and world-writable /images.

Step 5: Replace core and extensions from clean packages

Download the official full package for the same major version you are running. Diff or overwrite core folders (/administrator, /libraries, /includes, core /components) from that zip. Do not use this step to jump from Joomla 3 to Joomla 6. That is a migration, not a malware repair.

Reinstall templates and extensions from the vendor zip, not from the infected disk. Uninstall unused extensions. Delete their folders. Unpublish is not uninstall.

On the server, hunt recently changed files (SSH find by mtime is enough conceptually). Treat surprise PHP under media paths as guilty until proven otherwise. Reset permissions: folders 755, files 644, configuration.php 444. Never 777.

Step 6: Clean the database, not only the disk

File cleanup that leaves spam in #__modules, #__content, or #__extensions will republish the infection on the next page load.

• Dump the database, then search for spam domains, hidden iframes, and script tags you did not add
• Remove Super Users and extra admin accounts you cannot explain
• Check session and action logs if you keep them
• Review Joomla Scheduled Tasks for fetch-URL or PHP jobs you did not schedule

Do not run random “drop user” SQL you found on a 2014 blog. The old copy of this article even had invalid SQL. Use the User Manager, or a query you understand, on a backup copy first.

Step 7: Patch current, then rotate every secret

Update core to 6.1.3 or 5.4.8 (or newer if the project has moved on when you read this). Update every remaining extension, including JCE if you keep it. Then rotate:

• Every Super User and administrator password, plus 2FA
• Database password in the host panel and in configuration.php
• FTP, SFTP, hosting panel, Akeeba, payment, and SMTP secrets
• Joomla secret in configuration.php if you know how to regenerate it safely

If the attacker had Super User, assume they also had the database. A new password on the same leaked SMTP account is not a rotation.

Step 8: Prove it is gone, then talk to Google

Crawl the site as Googlebot and as a phone. Check .htaccess, ads.txt, and homepage HTML. Search your domain for spam queries. Take a new backup only after that.

Google is not one button:

• Safe Browsing warnings: wait for recrawl after the site is clean, then use Search Console security / malware reporting as Google documents it today
• Hacked content / spam in search: a different Search Console issue type. Cleaning files does not instantly drop spam URLs from the index. Use URL removal only for URLs that should not exist, not as a substitute for cleanup
• Request indexing is not a malware review. It will not lift a Safe Browsing flag

Expect days, not minutes, after a clean bill of health. Rankings recover after the warning and the spam URLs are gone, not after you “submit the sitemap again.”

Aftercare that actually prevents round two

• Stay on a supported line. 5.x regular bugfix ends 13 October 2026. Do not start a rebuild on 5.4 if you can start on 6.x. See the Joomla roadmap.
• 2FA on every administrator. Least privilege. No shared Super User.
• No nulled templates. That is still how a large share of “we were hacked for no reason” cases start.
• HTTPS is table stakes. It does not stop a vulnerable component.
• Off-server backups, tested restores, and a note of the last known-clean date.
• Admin Tools, RSFirewall, or equivalent help. They are not a substitute for updates.

If you are rebuilding after Joomla 3, that is an upgrade project, not a find-and-replace on a malware tree.

Key takeaways

1. Cleanup without a patch, or a patch without cleanup, fails.
2. Unpublish is not uninstall. Infected backups are not restores.
3. In August 2026, verify Joomla 5.4.8 or 6.1.3 and check JCE / VEL, not only “Joomla 4.3.”
4. Scan JavaScript, .htaccess, the database, and users, not only PHP signatures.
5. Google Safe Browsing review is separate from “request indexing.”

Frequently asked questions

How do I repair a hacked Joomla website?

Preserve an infected copy, take the site offline, identify the hole, replace core and extensions from official packages of the same major version, clean the database and rogue users, patch to current 5.4.8 or 6.1.3, rotate every secret, then request Google’s security review only after the site is actually clean.

Can I just update Joomla to remove malware?

No. Updates close the door. They do not delete PHP the attacker already wrote, extra Super Users, or spam in modules.

Is unpublishing a vulnerable Joomla extension enough?

No. Joomla’s documentation is explicit: uninstall it. Unpublish leaves files that can still run.

Should I restore my latest Akeeba backup?

Only if you are sure that backup is from before the compromise. A backup taken after the hack is a malware installer.

What Joomla version should I be on after a 2026 cleanup?

The current patched releases at this writing are Joomla 6.1.3 or 5.4.8. Check the security centre before you go live. Do not leave 6.1.2 or 5.4.7 as “good enough.”

Will Google rankings come back immediately?

No. Warnings and spam URLs clear on Google’s schedule after a successful review and recrawl. Indexing requests do not replace a malware review.

Conclusion

A hacked Joomla site is a persistence problem plus a patch problem. Treat it like both. If you want this done as a project rather than a weekend, we still clean and harden Joomla sites as part of support and maintenance. Bring the infected copy. Do not bring a guess.