Foreign ads and redirects
The site loads with unfamiliar banners or throws visitors to casinos, online pharmacies or shady pages, especially on phones and from search.
Joomla · Emergency help · Security
Hacked website recovery: I clear out the backdoors and close the hole they came through
I am Artem, and I specialize in Joomla. If your site redirects visitors to casinos, unfamiliar pages have shown up in search results, and your host has sent a malware notice, I will find and remove the web shells, clear injections out of the files and database, delete the fake administrators and close the entry point so the hack does not come back a day later. I always start with diagnostics.
Is your site down or infected right now? I take urgent cases first.
Message nowSound familiar?
This is what a hack looks like from the site owner's side. If even one point rings true, your site is most likely infected, and you need to act fast before the loss of traffic and reputation grows.
Spam in search results
In Google and Yandex, someone else's pages have replaced yours: hieroglyphs, products, pills. This is classic search spam injected through a hack.
A "site may be hacked" label
Search or the browser shows a "This site may be hacked" warning or blocks the visit. Visitors leave without ever opening the site.
Suspension by the host
The host has suspended the account for sending spam or for malware it found. The site and email stay down until the infection is removed.
Rogue administrators
Unknown super users have appeared in the admin panel, registration has switched on, and passwords no longer work.
Defaced homepage
Instead of your site there is a hacker's page or foreign banners. In the summer of 2026 a defacement signed "Hacked by AntonKill" is spreading widely.
Signs your site is hacked
A quick checklist. Check for yourself: the more matches, the higher the chance of infection.
- The site redirects visitors to unrelated pages (casinos, betting, pharma, adult content), often only from mobile or only when coming from search.
- Pages that are not yours have appeared under your domain in search results with spam keywords (brand replicas, medications), often with hieroglyphs (the Japanese keyword hack) in folders with random names.
- Google flags the site as "This site may be hacked", and the browser shows a red "Deceptive site ahead" warning or a malware one.
- Search Console has notified you that an unknown person verified ownership of the site, or hacked pages have appeared in the "Security issues" report.
- The homepage has been replaced with a hacker's message or foreign banners (a defacement, for example "Hacked by AntonKill").
- Super administrators you never created have appeared in the Joomla user list (plausible names, addresses on a non-existent domain).
- Organic traffic has dropped sharply due to deindexing or a block, and visits have collapsed for no visible reason.
- The server sends spam without your knowledge: outgoing emails bounce back, and the mail IP lands on RBL/DNSBL blacklists.
- The host has sent a notice about malware or excessive load, sometimes with an account suspension.
- Unfamiliar PHP files have appeared in the media, images and tmp folders, files with a double extension (.xml.php) or odd casing (.pHp).
Why Joomla is being hacked en masse right now
The summer of 2026 has been a season of mass automated attacks on Joomla, and the cause lies mainly not in the core but in popular extensions. One after another, critical vulnerabilities (CVSS up to 10.0) were disclosed that allow unauthenticated upload and execution of PHP code, meaning a full takeover of the site without a password: JCE / Joomla Content Editor (CVE-2026-48907, fixed in 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) and Page Builder CK (CVE-2026-56290, fixed in 3.6.0). Some were exploited as 0-day, before a patch even shipped, and all of them have been added by CISA to the catalog of actively exploited vulnerabilities (KEV). The exploits are public and the attacks are run by bots across the whole internet, so closed registration and low traffic do not save you from infection.
The scale is visible at the level of national CERTs too. On 9 July 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, and the list of vulnerable software names Joomla JCE outright. ACSC allows that the campaign is being accelerated by AI, which shortens the time from vulnerability disclosure to attack. In parallel there is a wave of homepage defacements signed "Hacked by AntonKill": Joomla-focused sources link it primarily to a separate vulnerability in the Helix3 template framework from JoomShaper (CVE-2026-49049), through which malicious code is injected straight into the template parameters in the database. Estimates of the number of infected sites are still rough: mySites.guru, for instance, observed hundreds of sites, but that is one source's estimate, not a verified total.
That said, most real Joomla hacks still happen not through fresh 0-days but for boring reasons: outdated core and extensions, weak or reused administrator passwords (Joomla does have two-factor authentication, but it is off by default), pirated (nulled) templates and components with a backdoor already baked in, and leaked credentials for the hosting, FTP and database. According to Sucuri, most CMS hacks trace back precisely to vulnerable third-party extensions rather than to the core itself. Worth remembering separately is the old but still actively scanned Joomla 4.x core hole CVE-2023-23752, a leak of the database login and password through the API, closed back in 4.2.8.
A key point that often gets underestimated: installing an update closes the way in, but does NOT remove what the attacker already left behind. Web shells, fake super administrators, malicious entries in .htaccess and cron jobs keep working even after the patch. So a site that ran a vulnerable version of an extension even briefly in June or July 2026 needs not just an update but a full cleanup and a check for persistence: by Google's observations, a notable share of hacked sites get re-infected within a day if the original hole is not closed.
Extension vulnerabilities, the main cause in 2026
Critical holes (CVSS up to 10.0) with unauthenticated PHP upload in JCE, SP Page Builder, iCagenda and Page Builder CK. The exploits are public and the attacks are run by bots.
Outdated core and components
According to Sucuri, most CMS hacks hit un-updated third-party add-ons. Plus the still-scanned old Joomla 4.x core hole CVE-2023-23752.
Weak and leaked credentials
Simple or reused passwords, no 2FA, leaked credentials for the hosting, FTP and database. A classic vector that needs no 0-day at all.
Pirated templates and extensions
Nulled builds of premium templates and components from untrusted sources often ship with a backdoor already built in that activates right after installation.
Automation and scale
On 9 July 2026 the ACSC warned of a global campaign of mass CMS scanning and web shell planting, possibly accelerated by AI. Targets are picked by brute force, not by hand.
A patch is not a cleanup
An update closes the way in, but does not remove the web shells, fake admins, .htaccess and cron edits already left behind. Without closing off the persistence, the site gets re-infected fast.
Affected extensions in 2026 (check and update): JCE to 2.9.99.5+, SP Page Builder to 6.6.2+, iCagenda to 4.0.8 / 3.9.15+, Page Builder CK to 3.6.0+, Helix3 (JoomShaper) per CVE-2026-49049. Data from NVD and the CISA KEV catalog. Updating is mandatory but not enough on its own: the site also needs to be checked for web shells and backdoors that are already installed.
How recovery works
A transparent order of work. Not just "cleaned up and gone": it matters to remove not only the symptoms but the cause, otherwise the site gets infected again through the same hole.
Diagnostics and evidence capture
I check the site with remote scanners and on the server, look at Search Console, Safe Browsing and blacklists, and identify the type of infection. I take a copy of the current state and the logs as evidence. The logs I copy first.
Finding the entry point in the logs
I study the access logs: I look for POST requests to vulnerable extension tasks, unusual uploads and the time of the first intrusion. That tells me exactly how they got in.
Comparison against a clean core
I download the official clean Joomla package for your version and compare it with the live site, separately searching for recently modified files. This exposes injections in the core, the template and index.php.
Cleaning the files and database
I remove injected code from the files and database tables: I look for eval, base64_decode, gzinflate, exec, injections in index.php and the template parameters. Where possible I replace infected files with originals rather than editing them by hand.
Finding and closing every backdoor
The key stage. I comb through media, images, tmp and non-standard folders for web shells, check .htaccess in every directory and the scheduler tasks for self-restoring jobs. One missed backdoor means a fast re-hack.
Clean reinstall and updates
I reinstall the Joomla core from a clean package, update extensions and templates from official sources, and remove vulnerable, unused and unfamiliar components against the Joomla Vulnerable Extensions List (VEL).
Rotating credentials and removing rogue admins
Only after the cleanup do I delete the fake super administrators, change all passwords and the credentials for the database, FTP/SSH and hosting, and rotate the configuration.php secret and the API keys. The order matters: while backdoors remain, changing passwords is pointless.
Verification and clearing the warnings
I rescan the site and confirm there is no malware and no stray outgoing requests. I request a review in Google Search Console and Yandex.Webmaster and ask the host to lift the block.
What you get
The result is not just "the site opens again" but a clean, updated and protected site, plus an understanding of what happened.
A clean, working site
No web shells, redirects, spam pages or defacement, verified by both a remote and a server-side scanner.
A closed entry point
Updated core and extensions and the patched vulnerability they came through, so the hack cannot repeat by the same path.
A pre-cleanup backup
A full snapshot of the hacked state and the logs, stored separately in case of an investigation or disputed points.
An infection report
A clear description: what I found (files, backdoors, rogue admins), where the hole was, what was removed and what was changed.
Refreshed credentials
Changed passwords for administrators, the database, FTP/SSH and hosting, and rotated configuration.php secrets and API keys.
Review requests
Requests to clear the warnings in Google Search Console and Yandex.Webmaster, and if needed a request to the host to lift the block.
Baseline hardening
2FA enabled for admins, restricted access to the panel, PHP execution disabled in the upload folders and other post-cleanup measures.
Recommendations for the future
A short checklist on updates, backups and monitoring to lower the risk of re-infection.
Work formats and timelines
I pick the format to fit the situation: from an urgent return of the site to service to a full recovery with protection and monitoring.
| Format | When it fits | What is included | Timeline |
|---|---|---|---|
| Emergency cleanup get the site back fast |
The site is infected or redirecting and needs to be back in working order fast. | Finding and removing the malware, clearing redirects and spam, basic closing of the entry point. | from a few hours |
| Full recovery and protection cleanup plus prevention |
Remove the infection and prevent a repeat. | Everything from the emergency plan plus a clean core, updates, credential changes, warning removal, protection and backups. | 1-5 days |
| Restore from backup or rebuild heavy cases |
The site is badly damaged and the backup is missing or also infected. | Deploying a clean copy or rebuilding on a clean core with content migration. | by scope |
| Monitoring and protection subscription |
Keep the site watched after the cleanup. | Monitoring, updates, backups and a fast response to incidents. | monthly |
* I quote the exact price after a free diagnostics: it depends on the type of infection, the size of the site and the state of the backups. I begin work only after the estimate is approved.
Protection after the cleanup
Cleaning up is not enough: it matters to close the entry and lower the risk of a repeat. Here is what I set up as part of a full recovery.
- I enable two-factor authentication (2FA) for all super administrators: in Joomla it is off by default.
- I restrict access to the /administrator folder by IP or password at the web server level.
- I disable PHP execution in the upload folders (media, images, tmp) so an uploaded file cannot become a working shell.
- I set strong, unique passwords for admins, the database, FTP/SSH and hosting, and remove any reuse.
- I close unauthenticated access to the configuration API endpoint at the server or Cloudflare level.
- I remove unused and unfamiliar extensions and templates, keep only what is needed and update from official channels.
- I drop pirated (nulled) templates and components and install only from trusted sources.
- I set up regular off-server backups with restore testing and, if needed, a WAF in front of the site.
Frequently asked questions
Not finding your question? Message me on Telegram, I will answer with specifics for your case.
How much does hacked website recovery cost?
It depends on the scale of the infection: cleaning a single injection in index.php is one thing, untangling a site with a dozen backdoors and fake administrators is another. That is why I start with diagnostics: I assess the scope and quote a clear price before any work begins, with no surprises along the way.
How long does recovery take?
Simple cases (a single redirect or injection) I often close within a few hours or a day. Heavy infections with multiple persistence points and clearing Google warnings can take several days. After diagnostics I give a realistic estimate for your site.
Can I lose data?
The first thing I do is make a full backup of the current state and work from it, rather than blindly on the live site. I aim to preserve content and settings in full. The only real risk is where the malware physically overwrote files, and I warn you about that in advance.
Can you guarantee the hack will not come back?
Honestly: no one can give a 100% guarantee on the web. But I close not just the symptoms but the entry point itself and every persistence mechanism (backdoors, .htaccess, cron), because it is exactly a missed hole that gets some sites re-infected within a day. I also harden the defenses so the old path no longer works.
Do you need access to the site?
Yes. A thorough cleanup requires access to the hosting or FTP/SSH and to the Joomla admin panel, sometimes to the database. A remote scanner only sees the frontend and misses server-side backdoors, so without file access the hack cannot be removed properly. You change all the credentials once the work is done.
Is it enough to just update Joomla and the extensions?
No. An update closes the way in, but it does not remove what the attacker already left behind: web shells, rogue admins, edits in .htaccess and cron jobs keep working even after the patch. So updating is a mandatory step, but not the only one.
What about simply rolling back to a backup?
Be careful: the official Joomla documentation warns outright that a rollback often just brings the hack back, because the infection may have made it into the backup along with the site. You should only roll back to a copy that was demonstrably made before the hack and verified clean. In other cases a clean reinstall is more reliable.
Do you work with WordPress and other CMS?
My main specialty is Joomla, where I know the quirks of templates, components and the typical persistence spots. The general cleanup principles (finding backdoors, closing the hole, clearing warnings) apply to WordPress too, and I can help with basic cases there, but I go deepest with Joomla.
Related services
A hack is often the result of an outdated site. Sometimes it is cheaper and safer not to patch the old one but to build anew on a clean foundation.
Site hacked? Let's start with free diagnostics
Describe the situation: what is happening with the site, which CMS it runs and whether you have access. I will take a look, identify the type of infection and the entry point, and tell you what needs to be done and by when. With no obligation to order further.