How to Scan a WordPress Website for Malware and Security Vulnerabilities

Scanning a WordPress website can help you find malware, suspicious file changes and known security vulnerabilities.

But there is an important limitation to understand before you start:

No single security scan can prove that a WordPress website is completely clean.

Different scanners look for different things.

A remote scanner can inspect what visitors can see from outside the website. A server-side scanner can examine files that are not publicly visible. A vulnerability scanner can identify software versions with known security issues. File integrity checks can tell you whether WordPress or plugin files differ from known originals.

Each gives you another piece of evidence.

If you are already seeing suspicious redirects, unknown administrator accounts, security warnings or other strange behaviour, start with our guide to signs your WordPress website may have been hacked.

If you want to investigate the website itself, the following steps give you a practical way to approach a WordPress security scan.

1. Understand what you are scanning for

Before choosing a scanner, it helps to know what question you are trying to answer.

There are several different things you may want to detect.

Malware

Malware is malicious code or content that has been placed on the website or server.

This can include things such as:

• malicious PHP files
• backdoors
• injected JavaScript
• malicious redirects
• spam content
• phishing pages
• code designed to create or maintain unauthorised access

A malware scanner looks for signs that malicious code or content may already be present.

Known vulnerabilities

A vulnerability scan looks for software with known security weaknesses.

For WordPress, this may include:

• WordPress core
• plugins
• themes

The scanner typically identifies the software and version being used, then compares that information against a vulnerability database.

Detection is not always complete, particularly with hidden, custom or unusually configured software, so the scan result still needs context.

A vulnerability warning does not automatically mean the website has been hacked.

It means a known weakness may be present and should be assessed.

Unexpected file changes

Malware is often introduced by adding new files or modifying existing ones.

File integrity checks can help identify differences between the files on your website and known clean copies.

This can be particularly useful for WordPress core files and plugins available from WordPress.org.

External security warnings

You may also want to check whether the website has been flagged by search engines, browsers or security services.

These warnings can provide useful evidence, particularly if visitors are already being shown security messages.

A thorough investigation may involve several of these checks rather than relying on just one.

2. Start with a remote website scan

A remote scan is usually the easiest place to begin because it does not require access to the website’s server.

The scanner visits the site in much the same way as an external visitor and examines what it can observe publicly.

Depending on the scanner, it may look for:

• malicious JavaScript
• suspicious redirects
• injected spam
• defacement
• suspicious external resources
• known malicious patterns
• security reputation or blocklist issues
• obvious signs of outdated software

This can be useful when visitors are reporting strange behaviour or when you want a quick external view of the site.

Remote scanning also has an important limitation.

It can only examine what the scanner can see from outside the website.

If malicious PHP code exists on the server but does not appear in the pages being scanned, a remote scanner may not detect it.

The same problem applies to conditional malware.

A malicious redirect might only be shown to visitors from a search engine, mobile users or people from a particular location. If the scanner does not trigger those conditions, the result may appear clean.

Treat a clean remote scan as useful evidence, not proof that nothing malicious exists.

3. Check WordPress core, plugins and themes for known vulnerabilities

The next step is to check whether the website is running software with known security vulnerabilities.

WordPress websites are made up of several independently maintained components. A site might be running an up-to-date version of WordPress while still using an old vulnerable plugin.

A vulnerability scanner can help identify:

• the WordPress version
• installed or detectable plugins
• installed or detectable themes
• known security issues associated with those versions

The important word here is known.

A vulnerability database can only report issues that have already been discovered, documented and added to its data.

The result also needs to be interpreted correctly.

If a plugin has a known vulnerability, that does not establish that somebody exploited it.

It means the website may have an exposure that needs attention.

Depending on the vulnerability, the appropriate response might be to:

• update the affected software
• replace it
• remove it if it is no longer required
• apply an available security patch
• investigate whether there is evidence the vulnerability was exploited

Vulnerability scanning is therefore useful for finding potential weaknesses, but it is different from looking for malware that is already present.

4. Run a server-side malware scan

If you have access to a server-side security scanner, it can inspect areas that a remote scanner cannot see.

Instead of only requesting public pages, a server-side scanner can examine files stored on the website.

Depending on the tool, it may look for:

• known malware signatures
• suspicious PHP
• backdoors
• unfamiliar files
• malicious code added to legitimate files
• recently modified files
• phishing content
• other suspicious patterns

Some tools may also examine database content or additional server data, but capabilities vary.

This is why it is worth understanding what your scanner actually checks rather than assuming every “malware scan” works in the same way.

A server-side scan is particularly valuable when a remote scan reports nothing but there are still strong reasons to suspect compromise.

For example, you might have:

• unexplained administrator accounts
• server-side malware warnings from your host
• unfamiliar PHP files
• visitors reporting conditional redirects
• suspicious file changes

Remote and server-side scanning complement each other because they view the website from different perspectives.

5. Verify WordPress core files with checksums

If you have command-line access to the site and WP-CLI is available, you can compare WordPress core files against the official checksums published for that version.

The basic command is:

wp core verify-checksums

If the WordPress core files match the official versions, WP-CLI will report that the installation verifies against the checksums.

If a core file has been changed unexpectedly, the command can identify the mismatch.

You can also include files in the WordPress root in the verification:

wp core verify-checksums --include-root

This can help surface unexpected items that are not part of the standard WordPress installation.

Checksum verification is valuable, but the result needs to be interpreted carefully.

A successful result does not mean the entire website is clean.

For example:

• malware could exist inside wp-content
• a malicious new file could exist outside the set being checked
• the database could contain injected content
• a plugin could be compromised
• an attacker could still have access through a stolen account

Think of checksum verification as answering a narrow question:

Do these WordPress core files match the official versions they are expected to match?

That is useful information, but it is not a complete malware scan.

6. Verify WordPress.org plugin files

WP-CLI can also verify checksums for plugins hosted on WordPress.org.

For all installed plugins, you can use:

wp plugin verify-checksums --all --strict

The --strict option also reports smaller differences that might otherwise be treated as less significant.

If a plugin’s installed files do not match its published checksums, the difference deserves investigation.

However, a mismatch does not automatically prove malware.

Files could have been:

• deliberately customised
• changed by a developer
• partially updated
• corrupted
• modified for another legitimate reason

You may also see warnings when WP-CLI cannot retrieve checksums for a plugin.

This is common with:

• premium plugins
• custom plugins
• software that is not distributed through WordPress.org

A missing checksum is therefore not a malware warning by itself.

It simply means this particular comparison cannot be performed against the WordPress.org checksum service.

For premium or custom software, you may need to compare the installed files with a known clean copy from the developer or investigate them another way.

7. Review anything the automated scans cannot explain

Automated scanners are useful because they can examine large amounts of information quickly.

They still need human interpretation.

Pay attention to anything that does not fit what you expect to see on the website.

That might include:

• administrator accounts nobody recognises
• unfamiliar files
• unexpected PHP in upload directories
• plugins nobody remembers installing
• unusual scheduled tasks
• settings that changed without explanation
• unexpected redirects
• strange database content
• security alerts from the hosting provider
• changes to premium or custom plugins that checksum tools cannot verify
• suspicious server or application logs

Context matters.

A recently modified file might be completely normal if you updated a plugin five minutes earlier.

The same modification becomes much more interesting if no update took place and visitors started reporting redirects at the same time.

A good investigation asks two questions repeatedly:

1. Is this expected?
2. Can we explain why it changed?

Anything that cannot be reasonably explained deserves closer examination.

8. Treat scanner warnings and false positives carefully

Security scanner results are not always black and white.

A scanner may flag something because the code resembles a malicious pattern even though it is legitimate.

For example, legitimate software sometimes uses functions or techniques that are also commonly found in malware.

Other warnings may simply indicate:

• a customised file
• generated or cached content
• a plugin the scanner cannot identify
• a premium plugin it cannot verify
• an outdated component that is vulnerable but not infected

That is why deleting every file a scanner labels as suspicious can cause additional damage.

The opposite mistake is just as dangerous.

A scan that reports no problems does not prove that the website is clean.

Malware can:

• hide in areas a particular scanner does not inspect
• activate only under certain conditions
• use code that does not match known signatures
• exist in the database rather than a file
• create unauthorised access without leaving an obvious visible payload

Security scanning is therefore about collecting and interpreting evidence, not chasing a single green tick.

9. What should you do if a scan finds malware?

If a scanner identifies possible malware, record what it found before making large numbers of changes.

Useful information includes:

• affected file paths
• scanner warnings
• timestamps
• suspicious URLs
• unfamiliar users
• detected vulnerabilities
• hosting alerts
• screenshots or exported scan results

Do not automatically delete every flagged file.

Some may be legitimate, while removing part of an infection without understanding the wider compromise can leave another backdoor or malicious change behind.

The next step is to establish the scope of the incident.

You may need to determine:

• what was changed
• how the attacker gained access
• whether administrator accounts were affected
• whether credentials need to be reset
• whether database content was modified
• whether vulnerable software was involved
• whether other malicious files remain

That moves beyond scanning and into proper malware cleanup and recovery.

10. How often should you scan a WordPress website?

There is no single scanning frequency that is right for every website.

A small brochure site that changes a few times a year has a different risk profile from an ecommerce store taking orders every day.

Consider factors such as:

• how important the website is to the business
• how frequently its software and content change
• whether it handles customer accounts or payments
• how many people have access
• how many plugins and integrations it relies on
• how quickly you would need to know about a compromise

For an important business website, ongoing automated monitoring is generally more useful than remembering to run an occasional manual scan.

Manual scanning still has a role when:

• you notice suspicious behaviour
• a vulnerability is announced in software you use
• your hosting provider sends a security alert
• you are investigating an incident
• you want an additional check after cleanup

Scanning should also sit within a broader security process.

Updates, account security, access control, backups, monitoring and secure hosting all matter too. Our guide to WordPress security best practices covers those preventative measures in more detail.

Does a clean malware scan mean your website is safe?

No.

This is one of the most important things to understand about website security scanning.

A scanner can only report on:

• what it checks
• what it can access
• what it recognises
• what was happening when the scan ran

A remote scan might miss server-side malware.

A file scanner might miss malicious content stored in the database.

A checksum check might confirm that WordPress core files are untouched while a malicious plugin or new PHP file exists elsewhere.

A vulnerability scan might report no known issues even though an attacker obtained a valid administrator password.

The strongest conclusion you can draw from a clean scan is:

That particular scan did not find evidence of a problem within the areas it checked.

That is still useful.

It is simply different from proving that no compromise exists anywhere on the website.

When there are strong indicators of compromise, keep investigating until the evidence makes sense rather than stopping because one automated tool reports that everything looks clean.

What if you already think your WordPress site has been hacked?

If visitors are being redirected, unknown users have appeared, Google is displaying security warnings or the website is behaving unexpectedly, scanning is only part of the investigation.

The warning signs covered earlier can help you decide whether there is enough evidence to justify a deeper investigation.

If you need someone to investigate an active compromise rather than handling the process yourself, our WordPress Malware Removal service is designed for hacked and infected WordPress websites.

We can investigate the problem, remove malicious content and help restore the website to normal operation.