What to Do When a Joomla Website Has Been Compromised

Contain the incident before trying to beautify the site

If compromise is confirmed or strongly suspected, prevent further public execution and attacker access. Joomla's security guidance recommends taking the website offline and working with the hosting provider. For a serious incident, server-level or web-server access restriction is preferable to relying only on Joomla's normal offline page, because compromised PHP may execute before Joomla can enforce application settings.

Preserve evidence

Before wiping files, save relevant web-server logs, hosting logs, database snapshots, suspicious files, timestamps, user lists, scheduled jobs, and configuration details in protected storage. Evidence can help identify the entry point and determine what credentials or neighboring systems were exposed. Do not publish secrets or malicious payloads while asking for help.

Notify the hosting provider

Ask the host to review account, web-server, malware, process, and authentication information that may not be visible inside Joomla. A compromise can originate from another account, stolen control-panel credentials, vulnerable server software, or a persistence mechanism outside the Joomla directory. Cleaning only Joomla cannot fix those causes.

Rotate credentials from a clean device

Change hosting, SFTP/SSH, database, Joomla administrator, API, deployment, and other relevant credentials after checking the administrative workstation for malware. Revoke unknown sessions, keys, tokens, and accounts. If a secret was stored in configuration.php or another exposed file, treat it as compromised and replace it.

Rebuild code from trusted sources

Joomla's recovery guidance favors replacing compromised files with clean copies. Use the correct Joomla release path and trusted current packages for extensions and templates. Do not preserve unknown PHP merely because the site depends on it. Custom code should come from verified source control or another known-good development source.

Review extensions, users, database, and persistence

Remove unused or vulnerable extensions completely, audit privileged users, inspect database content and configuration, and check scheduled jobs, startup hooks, writable upload areas, and neighboring sites. One visible backdoor may be only one persistence mechanism. Address the vulnerability or stolen credential that enabled the compromise.

Validate before returning to service

Update supported software, confirm permissions and HTTPS, test the site in a controlled environment, scan again, and review logs for renewed suspicious requests. Keep a known-clean backup after recovery. Document what was changed and monitor closely after reopening so recurrence is detected quickly.


Need More Help with Joomla?

Still having trouble? Open a support ticket with QuantaCade Support and we'll be happy to help where we can.

Support priority is given to QuantaCade products, services, and customers. However, we're also happy to assist fellow Joomla users with general Joomla questions and troubleshooting when possible.

QuantaCade is an independent Joomla extension developer and is not official Joomla support. Some issues involving third-party extensions, hosting environments, server configurations, or other systems outside our development control may be beyond what we're able to resolve.

Open a Support Ticket