Joomla hack: preserve evidence, clean up, report – lessons from our cleanups

Since 21 October 2026 we have examined a double-digit number of Joomla sites for a hack. Almost all of them were compromised. We rebuilt every site in an isolated copy without internet access, compared it with the original packages and, where they existed, analysed the server access logs. This post sums up what we found and the order in which site owners should act after a hack: take it offline, preserve evidence, find the cause, clean up, report. We do not name any clients.

What we found on the hacked sites

Attackers are fast and automated

On the morning of 21 October several sites were hit within one hour, some of them in the same quarter of an hour. Between the first attack request and the first response of the planted backdoor there were only seconds – hours before the vendor’s update came out that afternoon. Afterwards the access was apparently shared or sold: on one site more than twenty different addresses used the same backdoor within a few days, on another scanners were still looking for it a week later.

Look for backdoors after the update

An update closes the vulnerability, but not a backdoor that was placed before. If a vulnerability was exploited before the update came out, every security update therefore needs a check: which files are new or changed since the day of the vulnerability? Is there PHP in image, media, cache or temp folders? Are there new users or new extension profiles? Traces are not always in files. With a vulnerability in an editor it was foreign profiles in the database that allowed uploading program files – the editor update does not remove such profiles. In our maintenance this search is part of every security update for a vulnerability that has already been attacked.

What attackers leave behind

• Backdoors that look like images, in images or media, some named like Joomla files and with a backdated timestamp.
• Their own .htaccess files that lift an existing PHP block for single folders.
• Spam for search engines only: bots get gambling pages, visitors the real site. On one site search engines fetched tens of thousands of spam pages in one week. On another the attackers placed the Google Search Console verification file and could manage the domain in their own Google account.
• Malicious JavaScript in the template that sends visitors to foreign sites – in the administrator template too.
• A background process that restored deleted backdoors every second.
• Broken sites: on one site a failed attempt emptied dozens of files at once, after which it only showed error 500. Such an error is often the first thing the owner notices.

What was reachable

Whoever can run PHP on the server reads configuration.php and with it the whole database. On several sites it held hundreds to almost two thousand form submissions each, with names, e-mail addresses and partly phone numbers, on another the accounts of all members. Several times the password of a mailbox was in the configuration, on more than half of the sites complete backups including the database sat in the web space. Because all sites of a hosting plan run under the same user, other websites and old folders in the same plan were often reachable as well; in one case the attackers placed files there too.

The first hours: in this order

1. Take it offline, do not delete. Take the site offline at the host: rename the folder, block access or show a maintenance page with status 503. Joomla’s offline mode is not enough, because backdoors are separate files that bypass Joomla. Do not delete anything yet – every file is evidence.
2. Preserve evidence. A complete backup of the current state with files and database, plus the server’s access, FTP and error logs. Note checksums and the time. Many hosts keep logs for only days or a few weeks; in some of our cases exactly the days of the break-in were missing.
3. Record when you found out. From then on the 72 hours for a possible notification run. Write down who noticed what and when, for example through a warning mail from the host or a monitoring service.
4. Change access outside the site right away: the hosting account, FTP, SFTP and SSH, plus the mailbox whose password was in the configuration. Change the database password and Joomla’s secret during the cleanup – as long as a backdoor is active, the attackers read new values in configuration.php at once.
5. Involve the host. Ask for the logs, for blocked files and whether any processes are running in the web space. In our cases the hosts’ virus scanners blocked what they knew; on one site they missed some of the backdoors.

Forensics: what happened is in the logs

We never examine on the live server but in a copy without internet access, so no malicious code can call out and no mail goes to the site’s customers. We check:

• The Joomla core against the original package of the same version: every changed, missing or foreign file. Where core files were changed, it was exactly one each time, one that loads first on every request.
• The extensions against their original packages, where available.
• All files for patterns, images included: program code in image files, PHP in upload, cache and temp folders, foreign .htaccess, php.ini and .user.ini.
• The database: all text columns for scripts, iframes and foreign links, plus users, two-factor authentication, API tokens, scheduled tasks and extension profiles.
• The timeline from the access logs. File timestamps can be forged, and several attackers did so. The server logs are reliable: which request, which response, how large.
• The whole web space, not just the Joomla folder.

Joomla’s action log rarely helps. It is often missing in backups because backup extensions leave out the log folder, and several times the attackers had deleted the entries. The response sizes in the access logs, on the other hand, help narrow things down: on one site all attacker requests together received only a few hundred kilobytes. Downloading the database through the website was ruled out, other ways were not. Usually the result is “reachable, outflow neither proven nor ruled out” – and that is exactly what goes into the notification.

Cleaning up: rebuild instead of patching

• A clean starting point. The safest is a backup from before the break-in, but check it too. If there is none, remove the findings one by one, reinstall all Joomla core files from the original package and replace the extensions with fresh packages.
• Update first, then go online. Joomla and all extensions up to date before the site is reachable again. What nobody uses goes: old extensions, test folders, earlier installations, info.php, configuration.bak.php.
• New credentials everywhere: database password, Joomla’s secret (logs everyone out and invalidates API tokens), the passwords of all accounts with a change at the next login, two-factor authentication for administrators, the keys of the backup cloud storage (revoke them in the Google or Dropbox account and reconnect) and the connections of maintenance services.
• Backups off the server. Old full backups do not belong in the web space.
• Harden. Block PHP in images, media, tmp and cache via .htaccess. On one site this block turned away dozens of planted backdoors. Spam addresses Google already knows answer with status 410 so they drop out of the index.
• Check after going live: does Googlebot get the same page as visitors? Remove foreign owners in Search Console, look at the “Security issues” report and request a review after the cleanup.

A site on Joomla 3 or a PHP version without security updates stays offline after a hack until the migrated version is ready. It can be cleaned, but nobody closes the holes the attackers found any more. Which versions still get updates: Joomla versions and their end of life.

Reporting: who, to whom, by when

In every case personal data was readable for the attackers. Whether it actually left the server could usually be neither proven nor ruled out. Under the GDPR that does not matter: a personal data breach is already the unauthorised access to the data, not only its proven outflow.

• Data protection authority
  The site owner (company, club, school) notifies the breach as controller, unless it is unlikely to result in a risk to the people concerned. Deadline: without undue delay, where feasible within 72 hours of becoming aware; missing details may follow later (Art. 33 GDPR).
• People concerned
  The site owner informs them without undue delay if there is a high risk, for example with passwords, bank or health data (Art. 34 GDPR).
• Own records
  Every breach is documented, even if no notification is needed (Art. 33(5) GDPR).
• Site owner
  Agency, host and maintenance service inform the owner as processors without undue delay as soon as they notice the hack (Art. 33(2) GDPR).
• Police
  Report the attack early and with the preserved logs; in Germany businesses, associations and educational institutions go to the cybercrime contact point (ZAC) of their state.
• Google
  Request a review in the “Security issues” report of Search Console after the cleanup.

Do not wait for the finished analysis before notifying; the GDPR expressly allows providing details in phases. Anyone who stored card data also informs their payment provider. This is not legal advice: whether to notify is the site owner’s decision, ideally together with their data protection officer. Our findings reports contain what a notification needs – what was reachable, since when, which data and what was done.

Prevention: what would have helped in these cases

1. Security updates on the day they are released, followed by a search for backdoors if the vulnerability was already attacked. Almost all break-ins went through known vulnerabilities in extensions. Which ones are being exploited right now is in our list Vulnerabilities in Joomla extensions 2026.
2. What is not there cannot be attacked: unused extensions, old installations and test folders in the same plan, info.php, configuration.bak.php.
3. No backups in the web space. Backups belong off site, encrypted, with their own storage location and their own key per site. Tools for this, tested: Backup extensions for Joomla 6.
4. Block PHP where only files belong: images, media, tmp, cache.
5. Turn logs on and keep copies. Enable access logs at the host and store them regularly outside the server.
6. Store less. Delete form submissions that arrive by mail anyway after a few days. One site had contact requests from many years in its database.
7. Two-factor authentication and fewer accounts. None of the break-ins used the backend, but the attackers could read password hashes and Joomla’s secret. On more than half of the sites no administrator had two-factor authentication. Switch off unused accounts and API tokens.
8. Monitor. Have core files and new files checked regularly and connect Google Search Console. Several of these hacks were first noticed by a maintenance service or the host. What the services check: Joomla site management tools compared.
9. Have an emergency plan: who decides to take the site offline, who has access to the host, where are logs and backups, who is the data protection officer?

How we worked

The basis is a double-digit number of examinations from 21 October to 9 November 2026, Joomla 3.10 to 6.2, with several hosts. Every examination started with a backup of the infected state, which we restored in Docker without internet access. Then came the comparison with the original packages of Joomla and the extensions, a pattern check of all files and all text columns of the database and, where they existed, the analysis of the access logs. We deliberately name no clients, file names or attacker addresses.

Sources: Art. 33 GDPR · Art. 34 GDPR · Google Search Console: Security issues report