Compromised Joomla 3 site: assess, contain and recover
- Joomla
- September 8, 2025
Table of contents
Unexpected redirects, new privileged accounts or unauthorised content call for a Joomla 3 compromise investigation. Start by containing the impact while preserving information about what happened. Deleting the first reported file does not demonstrate that an attacker’s access has been removed.
Joomla 3 is unsupported. Recovery therefore needs to address both the incident and the unsupported platform. Cleanup does not restore CMS support or guarantee protection against future attacks.
Distinguish indicators from confirmed findings
Record what happened, where and when. Slowness or an unfamiliar filename alone is inconclusive; an unauthorised account or verified injected code requires investigation of the affected scope.
| Indicator | Evidence to retain |
|---|---|
| Unexpected redirect | Starting URL, destination, session and visit conditions |
| Unknown account | Identifier, groups and documented activity |
| Altered files | Preserved copy and comparison with a trusted version |
| Spam pages or links | URLs and content actually returned |
| Hosting alert | Paths, timestamps and reason supplied by the provider |
Do not execute suspicious files or follow instructions displayed by altered pages. Keep screenshots and logs without publicly exposing credentials or user data.
Contain access while preserving evidence
Ask the host to assess isolation and restrictions on affected functions. Joomla’s offline setting does not necessarily prevent access to every file or endpoint. Hosting-level controls may be needed when harmful content is being served.
Preserve available files, database and logs separately, clearly marking the copy as compromised. It is evidence, not a clean restoration point. Record the time and purpose of changes because updates and deletions alter the state under investigation.
Use a trusted device for administration. Decide which notifications, transactions and integrations must pause. Containment should reduce exposure while keeping the status of unavailable services clear.
Review Joomla users, extensions and configuration
Inspect privileged accounts and group memberships, along with recently installed or enabled extensions. Include system plugins, templates, overrides, libraries and files in uploaded-content directories.
Official-package comparisons expose differences but require interpretation. Legitimate custom code and injected code may both differ from the distribution. Use a trusted baseline and an inventory of authorised changes.
Inspect output-producing data, custom HTML modules, redirects and server configuration as well. A PHP-file scan does not examine everything capable of changing the public page.
Keep findings tied to their source. An external alert, a file difference and a confirmed unauthorised account provide different kinds of evidence and should not be reported as interchangeable conclusions.
Investigate the entry point without assumptions
Correlate access and modification records where logs permit. Check exact versions against the Joomla Security Centre and Vulnerable Extensions List. A matching version is a relevant lead, not proof that the listed vulnerability was exploited in this incident.
Do not blame core or the oldest plugin solely because of age. Stolen credentials, hosting access or another site sharing the account may be involved. If the logs cannot establish entry, record that limitation.
Distinguishing confirmed findings from hypotheses determines which access needs revocation and which controls must remain during recovery.
Choose a verified rebuild or restoration path
The Joomla compromised-site checklist highlights persistent access and already infected backups. The first observed symptom does not necessarily mark the intrusion date.
Evaluate backups and packages in isolation. When rebuilding, retain only verified content and customisations, accounting for added files that overwriting a standard package would leave behind.
Do not overlay a new Joomla major release onto the old installation as a shortcut during cleanup. Migration must be consistent with database and extension requirements. A backup restore also needs separate consideration of orders, registrations and content created afterwards.
Revoke access and investigate recurrence
Review passwords, hosting and SFTP or SSH access, database credentials and potentially exposed integration secrets. Plan rotation and revocation from a trusted environment, coordinating configuration changes in applications that use those credentials.
In a hypothetical incident, removing an altered file stops the redirect while an unauthorised administrator account remains. Public behaviour improves, but access persists. Verification must therefore include files, accounts and configuration.
After recovery, compare the installation with the trusted baseline and investigate unexpected changes. If the symptom returns, preserve the new evidence and reassess the hosting scope rather than repeatedly deleting the same file.
Define reopening criteria and the migration follow-up
Test reported pages, authentication, forms, search and extension functions. Verify that authorised users can work and revoked access cannot be reused. Handle external security flags through the relevant service’s review process after remediation.
Document the established cause, removed elements, recovered data and unverified areas. Follow-up should include a supported platform and assessment of extensions to retain or replace.
If you suspect an attack, I can assess the Joomla compromise scope and prepare recovery around the evidence and usable copies available.
