How to Check Whether Joomla 5 Has a Virus: Symptoms and Diagnostics
A Joomla 5 infection does not always cause a website to go offline immediately. Malicious code may run in the background, redirect only some users, create spam pages for Google, send messages, or maintain hidden access to the server.
The website may therefore look normal to the administrator while posing a risk to visitors and other websites hosted under the same account.
Detecting an infection should involve more than an automated file scan. It should also include checking the database, user accounts, extensions, scheduled tasks, PHP configuration, and server logs.
The most common signs of a Joomla 5 infection
1. The website redirects to another domain
One of the most characteristic symptoms is a redirect to an advertising service, fake contest, gambling website, shop selling medicines or supplements, message claiming there is a virus, or a website impersonating a bank or payment provider.
The redirect may be triggered only on mobile devices, on the first visit, after arriving from Google, for users who are not logged in, from specific IP addresses, or after clicking a particular element.
As a result, an administrator who is logged in and repeatedly visits the website from the same computer may not see the problem.
2. Unfamiliar subpages have appeared on Google
Search results may contain URLs about casinos, medicines, loans, cryptocurrencies, adult content, fake shops, or products the website has never offered.
The titles may be written in Japanese, Chinese, Russian, or English. Sometimes, when an administrator opens such a URL, they see a 404 error, while the search engine’s crawler receives generated spam content. This technique is often called SEO spam or cloaking.
3. The hosting provider has detected malicious files
The hosting provider may send a notice about infected PHP files, spam being sent, excessive CPU usage, attempts to attack other servers, detected phishing, automatic domain blocking, or suspension of the entire hosting account.
The files identified by the hosting provider do not have to be the source of the break-in—they are often only one part of a larger infection. Deleting only the files listed in the message does not ensure that the attacker has lost access.
4. Unknown PHP files appear on the server
Pay particular attention to PHP files in directories mainly intended for media or caching, such as /images/, /media/, /tmp/, /cache/, template subdirectories, or extension directories.
Potential warning signs include:
- files with random names
- files impersonating system components
- several files with almost identical contents
- scripts that recreate themselves after deletion
- code containing long encoded strings
- references to external servers
Not every PHP file in an unusual directory is a virus. Do not delete one based only on its name or location.
5. An unknown administrator has appeared
Check users with Super Users, Administrator, Manager, or other groups that have backend access. Verify the mapping of users to groups directly in the database.
Warning signs include:
- an unknown user in the Super Users group
- a changed administrator email address
- a new account created without the owner’s knowledge
- an account with a name resembling a system component
- an unexpected password change or loss of backend access
6. The .htaccess file has changed
Malicious rules in .htaccess may redirect users, hide spam pages, run files with unusual extensions as PHP, block the administrator’s access, or show different content to Google’s crawlers.
Check both the main .htaccess file and files in subdirectories. Do not automatically replace the entire configuration with the standard htaccess.txt file—the website may have legitimate rules for redirects, SSL, or directory protection.
7. The website is using excessive resources
A sudden increase in CPU, memory, or bandwidth usage may result from sending spam, mass creation of subpages, cryptocurrency mining, executing remote commands, or generating a large number of errors. It still needs to be investigated, since it may also be caused by an extension error or misconfigured cache.
Joomla 5 diagnostics, step by step
Step 1. Secure a copy of the current state
Before making any changes, back up all files, the database, server logs, hosting configuration, cron jobs, and messages from the hosting provider. The backup may be infected, but it serves as evidence and protects against data loss. Do not store the backup in a publicly accessible website directory.
Step 2. Check the exact Joomla version
In the backend, go to System → Information → System Information. Joomla 5 provides information here about the PHP version, server, database, configuration, and directory permissions. Compare the installed version with the current release in the official repository—older releases may be vulnerable to known issues.
Step 3. Check the extensions
In Joomla, go to System → Manage → Extensions and check every extension: its name, developer, installation date, version, status, and compatibility with Joomla 5. Look for extensions you do not recognize. Then go to System → Update → Extensions and check for available updates. The absence of update information does not mean an extension is safe.
Step 4. Check scheduled tasks
In Joomla 5, go to System → Manage → Scheduled Tasks and check each task, its type, schedule, and status. Since Joomla 5.3, an execution history is available and may help identify unusual activity. Also check cron jobs configured in the hosting control panel.
Step 5. Compare the system files
Download the complete package for exactly the same Joomla version from an official source and compare it with the files on the server. Look for modified core files, additional files in system directories, unknown code at the beginning or end of a file, and changes in the /administrator/, /api/, /includes/, /libraries/, and /plugins/ directories. Do not compare file size alone—use checksums.
Step 6. Review configuration.php
Check the database credentials, paths to the log and temporary directories, debugging settings, cookie domain, and HTTPS enforcement—and, above all, check for any extra code before or after the configuration class, additional include or require statements, or references to unknown files. Do not publish the contents of configuration.php—the file contains database credentials.
Step 7. Check the database
The review should cover users and their assigned groups, the list of extensions, active system plugins, modules with custom HTML, article content, menu items, template configuration, scheduled tasks, and user sessions.
Look especially for JavaScript, iframe elements, unknown domains, encoded fragments, hidden links, and accounts with elevated privileges. Do not run a global find-and-replace operation without a database backup.
Step 8. Analyze the logs
Check HTTP request logs, PHP error logs, FTP and SFTP logs, SSH login logs, hosting-control-panel history, WAF firewall logs, and email-sending logs. Look for activity shortly before the malicious file first appeared or the hosting provider sent a notification. Remember that an attacker may change a file’s modification date.
Is an automated scanner enough?
A scanner is useful for detecting known signatures, identifying modified files, finding suspicious functions, and checking domains against warning lists. However, it cannot independently confirm that the database is clean, that no hidden administrator account exists, that cron is not restoring the infection, or that other websites on the hosting account are safe.
A result stating “no threats found” is not proof that there is no infection.
When is a professional analysis needed?
Professional help is recommended when:
- the infection keeps returning
- the hosting provider has blocked the account
- several websites are running on the server
- the website processes customer data
- there is no reliable backup
- SEO spam has appeared on Google
- a Super User account has been taken over
- legitimate files cannot be clearly distinguished from malicious ones