• The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • Debian 11 has reached its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.81 is the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Issue Joomla website hacked

LaurentR2D2

Regular Pleskian
Plesk Certified Professional
Server operating system version
Debian 12.15
Plesk version and microupdate number
Plesk Obsidian v18.0.80_build1800260918.14 os_Debian 12.0
Plesk Obsidian v18.0.80_build1800260918.14 os_Debian 12.0
Debian 12.15
PHP 8.4.25
Joomla! 6.1.3 Stable [ Nyota ] 18-August-2026 16:00 UTC

Hello,

This is the second time my Joomla site has been hacked, and I’ve had to reinstall it. It’s the same thing every time. I end up with additional WordPress wp-* files. The index.php and configuration.php files are modified, and I can no longer access the site or the admin panel. The homepage displays a blank page, and the admin panel shows a message like “WordPress Briefly unavailable for scheduled maintenance. Check back in a few hours.” The permissions for the httpdocs folder have also been changed from 750 to 555. The first time, I've changed the FTP password as well as the SSH passwords for my server and reinstalled Joomla from my Akeeba backup. It wasn’t even a week before it happened again.

I don't know where to look to fix the security problem of my server. I have other websites hosted on my server, and none of them have a problem (wordpress, simplemachine forum, basic html website).

Thank you
 
To be honest restoring from backups isn't going to be enough to keep them out if they were in for awhile and you will need to know how they're getting in. Review access logs and such. Check in phpMyAdmin for any admin accounts in #__users table, etc.

You'll also want to make sure you change the passwords to any additional FTP users, SSH keys, database user password, every joomla admin, SMTP/API keys, and the $secret inside the configuration.php.

Also, check what extensions, themes, etc., you have installed. Even though you have the latest version of Joomla installed doesn't help if there's an extension or theme that's outdated and open for attacks.

Ideally you would just want to do a complete clean install of Joomla and only restore the content (images/media) and maybe the database if you know that the database is clean.
 
I've found AI, in particular chatGPT, to be a great help in analyzing hacked websites and getting details on possible entry points. If you upload your website files, access logs and database you can get AI to analyze everything and ask for security recommendations afterwards.
 
As far as I understand, this has happened twice, with almost identical symptoms, so the underlying entry point may still be present, or something on the server is allowing the attacker to regain access. Restoring Joomla from a backup and changing a few passwords may not be enough if the original vulnerability or persistence mechanism hasn't been identified.

That is why, before reinstalling again, preserve a copy of the compromised files and relevant logs for analysis.
Check the following in Plesk:
Web server access and error logs, especially requests immediately before the first suspicious file appeared.
SSH authentication logs and FTP/SFTP activity, looking for unfamiliar IP addresses, successful logins, or unexpected file uploads.
Plesk's login history and scheduled tasks (cron jobs) for unfamiliar accounts or commands.
PHP-FPM and PHP error logs for suspicious scripts or unexpected execution.

Look for recently modified files, unexpected PHP files in writable directories, and unfamiliar files outside `httpdocs` that could be used to reinfect the website. Correlate file modification timestamps with the logs where possible. It is important to note that timestamps can be altered, and the absence of suspicious log entries doesn't prove the server is clean.

Make sure to check for persistence and compromised credentials. Changing the FTP and SSH passwords is a good start, but it is also important to review:
All Plesk, system, FTP/SFTP, SSH, and Joomla administrator accounts
Authorized SSH keys, additional FTP accounts, and any unexpected system users
Scheduled tasks, startup scripts, and other mechanisms that could recreate malicious files
Database users and Joomla administrator accounts. Review the Joomla users table (typically `#__users`, where `#_` is replaced by the site's table prefix) and check for unfamiliar accounts or unexpected privilege assignments
Database credentials, API tokens, SMTP credentials, and other secrets that may have been exposed

Rotate affected credentials from a known-clean device, and revoke any suspicious SSH keys or sessions. If the attacker obtained root access, changing website credentials alone won't be sufficient.

Thoroughly audit Joomla and its extensions. Even when Joomla core is up to date, a vulnerable third-party extension, template, or custom component can provide an entry point. Inventory all installed extensions and templates, verify their sources and versions, and check whether any have known vulnerabilities. Remove anything unused or untrusted. Also, verify that the Joomla core files match a clean copy of the exact release you're running. Don't assume that every file is legitimate just because its name looks familiar.

Don't forget to perform a clean recovery. If the entry point remains unknown, I'd avoid simply restoring the entire backup. A safer approach is to prepare a clean Joomla installation, install verified extensions, and restore only reviewed content and necessary data. Scan uploaded media and other writable directories for executable files, and review the database before importing it. A backup created after the initial compromise may already contain a backdoor. Restore appropriate ownership and permissions based on Plesk's configuration and Joomla's requirements.

I would like to add that AI tools can help review sanitized logs, suspicious PHP snippets, file listings, and differences against clean Joomla files. However, I wouldn't upload a complete production database, configuration files, or website archive containing passwords, private customer data, session tokens, or API keys to a public AI service. Remove sensitive information first.
 
Hello. Thank you for all your answers. I've found the website : mySites.guru: Manage & Secure WordPress and Joomla Sites which has helped me identify not only the faulty extension, but also to remove a lot of files not supposed to be on my Joomla installation. The faulty extension was JCE editor which contained a security breach at some point. New versions are fixed. I have no problem with my Joomla site since then.
 
Back
Top