A Joomla site starts redirecting visitors to an unfamiliar domain. The administrator searches for a “Joomla malware scanner,” runs an external security check, and gets a list of exposed technologies and configuration issues. Is the site clean because no malware was reported? No. The wrong tool may have been asked the wrong question.
Malware scanning and vulnerability scanning overlap in a security investigation, but they are not the same job. One looks for signs that a site or server has already been compromised. The other looks for weaknesses that could make compromise easier or show where the public surface is exposed. Confusing the two can lead to false reassurance.
This guide is written for site owners, agencies, and administrators who need to decide what to do when a Joomla site looks suspicious, has just been patched, or simply needs a routine security review.
The short version
A malware scan is primarily looking for malicious or unauthorized code, files, modifications, persistence, or behavior on the server or in the application. A vulnerability scan is primarily looking for weaknesses, exposed components, risky configuration, known vulnerable versions, or externally observable conditions that could be abused.
One can exist without the other. A site may be vulnerable but not compromised. A site may also be compromised even after the original vulnerability has been patched. That is why a post-incident workflow often needs both kinds of investigation.
What a Joomla vulnerability scan can tell you
A Joomla-aware vulnerability review can help answer questions such as:
- Does the public site expose clear Joomla fingerprints?
- Are extension or template clues visible from the outside?
- Are public routes, installation remnants, administrative surfaces, or other known locations exposed?
- Are browser-side controls such as headers and cookies weak?
- Does the visible stack suggest outdated or risky components that need verification?
- Has a migration, extension change, or hardening step altered the public surface?
Vulnify’s Joomla Stack Checker is designed for this kind of external, Joomla-aware profiling. It can provide a quick baseline and, in broader account-backed workflows, deeper route and component evidence. It is useful for understanding what an attacker can observe without logging into the site.
That is different from reading every PHP file on the server or inspecting a process list for a backdoor.
What a malware scan is trying to find
A server-side malware investigation is concerned with compromise evidence. Depending on the environment and tooling, that can include:
- unexpected PHP, JavaScript, or configuration files;
- modified Joomla core files;
- web shells or obfuscated code;
- malicious scheduled tasks or persistence mechanisms;
- unexpected administrator accounts;
- injected redirects or advertising code;
- changes to
.htaccess, web server rules, or entry-point files; - malicious database content or injected scripts;
- outbound connections, suspicious processes, or unauthorized cron jobs;
- files changed outside the expected deployment or update window.
This kind of inspection usually requires filesystem, database, hosting, endpoint, or control-panel access. An external public-surface scanner cannot honestly claim to prove that every server-side file is clean.
Incident example: visitors are being redirected
Imagine a Joomla site that looks normal to the administrator but some visitors report being sent to a gambling site. The redirect happens only on mobile devices and only once per day.
An external vulnerability scan may show that Joomla is present, one extension appears old, and the site has weak security headers. Those findings are useful, but none of them proves what is causing the redirect.
The investigation should now move in two directions.
First, treat this as a possible compromise. Check recently modified files, Joomla administrator accounts, extension changes, templates, database content, scheduled jobs, web server rules, and access logs. Compare core files with trusted release packages or integrity data where available. Inspect injected JavaScript and unfamiliar external domains.
Second, review the public attack surface. If an old extension is exposed or a risky route remains accessible, it may explain how the attacker got in or show that the same weakness remains available after cleanup.
The correct conclusion is not “the vulnerability scanner missed malware.” It is “the vulnerability scanner answered a different part of the incident.”
When vulnerability scanning is the right starting point
Use vulnerability scanning when the main question is, “What does this Joomla site expose right now?”
Typical situations include:
- after installing or updating extensions;
- after a Joomla core update;
- after moving hosting providers;
- before launching a redesigned site;
- during a routine external security review;
- after removing an old extension or template;
- after remediation, to confirm the public surface changed as expected.
Vulnify’s existing Joomla vulnerability scanning guide explains how external checks fit into extension, template, core, and endpoint review without pretending to replace internal inspection.
When a malware investigation should take priority
If there are signs of active compromise, start incident response rather than assuming a routine vulnerability scan is enough.
Warning signs include:
- unexpected redirects;
- new administrator accounts you did not create;
- SEO spam or unfamiliar pages appearing in search results;
- modified files that nobody on the team recognizes;
- new JavaScript loaded from unknown domains;
- emails being sent from the site without explanation;
- hosting abuse warnings;
- unexpected CPU usage or outbound traffic;
- security products flagging malicious files;
- repeat reinfection after a superficial cleanup.
At that point, preserve evidence before deleting everything. A compromised Joomla site may have more than one persistence mechanism. Removing the visible malicious file without finding the initial access path can lead to reinfection.
A practical compromise workflow
1. Contain the site
Restrict administrative access, preserve logs, and isolate the affected environment if necessary. If customer data or privileged accounts may be exposed, follow the organization’s incident-response process rather than treating the event as routine maintenance.
2. Preserve evidence
Before overwriting files, collect timestamps, relevant logs, suspicious files, administrator-account history, extension lists, and a copy of the affected environment if your incident process allows it. Evidence can help identify when the compromise began and what the attacker changed.
3. Review files and database content
Compare Joomla core files against a trusted release. Check template files, extension directories, web server rules, configuration files, uploaded media, and database content for unexpected scripts or links. Do not assume the malicious code is limited to one directory.
4. Review accounts and secrets
Check Joomla administrator accounts, hosting accounts, SFTP/SSH credentials, database credentials, API keys, and control-panel users. Rotate credentials that may have been exposed and invalidate stale sessions where possible.
5. Patch or remove the entry point
If a vulnerable extension, outdated Joomla core version, or exposed service appears to be the entry point, update or remove it before bringing the environment fully back into service.
6. Validate externally
After cleanup and patching, run the Joomla Stack Checker and a broader Website Vulnerability Scanner review. This does not certify the server as malware-free. It helps confirm that externally visible risks, exposed routes, browser controls, and component clues now look the way you expect.
Why file integrity matters on Joomla
Attackers often modify legitimate files because a changed core or template file blends in better than an obviously named backdoor. File integrity comparison can help identify code that differs from the trusted package or from your own source-controlled deployment.
The important word is trusted. Comparing a compromised server against a backup taken after the compromise only proves the two copies match. Use known-good release packages, source control, deployment artifacts, or integrity baselines created before the incident.
Extensions create two different risks
Joomla extensions matter in both vulnerability and malware investigations.
An extension can contain a vulnerability that gives an attacker access. Separately, a compromised or malicious extension package can itself introduce unwanted code. Those are different problems. One is a software flaw. The other is a supply-chain or integrity problem.
That is why extension review should include both security history and provenance: where the extension came from, whether it is maintained, whether the installed version is expected, and whether its files match what the team intended to deploy.
Do not forget the database
Malware investigations often focus on files, but Joomla content lives heavily in the database. An attacker may inject scripts into articles, modules, templates, configuration values, or user-controlled content without leaving an obvious new PHP file.
If visitors see malicious JavaScript or redirects, inspect both filesystem and database sources that contribute to the final HTML response.
What Vulnify can and cannot tell you
Vulnify is well suited to external validation. The Joomla Stack Checker can identify Joomla-related public signals and prioritize visible risks. The Website Vulnerability Scanner can broaden that view across common web weaknesses.
Vulnify should not be treated as a server-side antivirus product, an EDR platform, or a forensic filesystem scanner. A clean external result does not prove there is no malicious code on the host. Conversely, an external finding can be valuable even when the site is not compromised because it highlights conditions worth fixing before someone abuses them.
Decision guide
Question: "Is my Joomla site exposed or misconfigured?"
Use: External vulnerability and stack scanning
Question: "Has someone modified files or planted malicious code?"
Use: Server-side malware and integrity investigation
Question: "We cleaned a compromise. Is the public surface now safer?"
Use: Both internal incident validation and external re-scanning
Question: "An extension looks old. Are we hacked?"
Answer: Not necessarily. Verify the extension risk, then look for compromise evidence separately.Use the right tool for the question
Joomla malware scanning and vulnerability scanning belong in the same security program, but they should not be confused. Malware investigation asks whether the environment has been altered or compromised. Vulnerability scanning asks what weaknesses and exposures are visible and potentially exploitable.
When a site is behaving suspiciously, investigate compromise first and preserve evidence. When a site is stable, use vulnerability scanning to reduce the chance of compromise. After an incident, use both: clean and investigate internally, then validate the public surface so the same path is not left open.