DEV Community: MD Pabel

WordPress Malware Removal Is Not Just “Delete the Bad File

MD Pabel — Sat, 29 Aug 2026 20:00:25 +0000

When a WordPress site is hacked, the obvious approach is usually:

Find the malicious file
Delete it
Run a malware scanner
Assume the site is clean

That works for simple infections.

But in more advanced cases, the malicious file you can see is only one part of the compromise.

The real problem is often persistence.

A site can look clean after remediation and then become infected again because another component is still capable of restoring the malware.

Malware can exist across several WordPress layers

In real cleanup cases, I have found malicious code or persistence mechanisms in places like:

wp-content/mu-plugins/
Fake WordPress plugins
Theme functions.php
Database options table
Cron jobs
.user.ini
Service workers
Compromised uploads
Random PHP files inside wp-content
Modified WordPress core files
Injected JavaScript
Hidden administrator accounts
Hosting-level configuration

The important part is that these components may not operate independently.

For example:

Cron
  ↓
Malicious PHP file
  ↓
Database option
  ↓
Injected JavaScript

Deleting only the PHP file may solve the visible symptom temporarily while leaving the restoration mechanism untouched.

A clean scan is not proof that the site is clean

Malware scanners are useful.

I use them too.

But a scanner result should be treated as a signal, not absolute proof.

During a proper investigation, I also want answers to questions such as:

Were any administrator accounts created?
Were plugin files modified?
Is there an unfamiliar fake plugin?
Are there suspicious entries in the database?
Are cron jobs loading unknown code?
Has .user.ini been modified?
Is another website in the same hosting account compromised?
Are credentials still exposed?
Are SEO spam URLs still indexed?
Is the domain blacklisted?
What caused the compromise in the first place?

And most importantly:

What can recreate the malware after I delete it?

That question is often more valuable than simply asking where the malware is.

Reinfection does not always mean the attacker hacked the site again

This distinction matters.

Suppose you remove a malicious file at:

wp-content/uploads/example.php

A few hours later, it appears again.

It is tempting to conclude:

“The attacker got back into the site.”

Maybe.

But another possibility is that something already present on the server restored it.

That could be:

cron

or:

.user.ini

or a malicious database entry, fake plugin, mu-plugin, theme injection, or another PHP loader.

In that situation, the second infection is not necessarily a second intrusion.

It is the original compromise continuing to operate.

One recent case used multiple persistence paths

I recently investigated a WordPress infection where malicious components were distributed across several locations.

The persistence involved areas such as:

mu-plugins
fake plugin
theme functions.php
database options table
cron
.user.ini
service workers
wp-content files

Removing one component was not enough.

Several pieces could contribute to restoring or loading other malicious components.

This kind of case changes the way you approach remediation.

Instead of thinking:

Find malware → Delete malware

the workflow becomes closer to:

Detect symptoms
      ↓
Map compromised components
      ↓
Identify relationships
      ↓
Remove persistence
      ↓
Remove payloads
      ↓
Find initial access
      ↓
Verify cleanup
      ↓
Monitor for reinfection

My general WordPress malware cleanup workflow

I prefer to separate remediation into several stages.

1. Confirm the compromise

Before deleting anything, identify the symptoms.

Examples:

Redirects
Spam pages
Unknown JavaScript
New admin accounts
Browser warnings
Google Safe Browsing alerts
Suspicious PHP files
Modified plugin files

2. Determine the scope

Do not assume only one website or one directory is affected.

Check:

WordPress files
database
hosting account
other websites
server configuration
DNS/CDN
administrator accounts
scheduled tasks

3. Investigate persistence

This is one of the most important steps.

Search for anything capable of restoring another malicious component.

4. Remove malicious components

Only after understanding the relationships between them should cleanup begin.

Otherwise you can end up deleting symptoms while leaving the mechanism alive.

5. Investigate the entry point

Potential causes include:

Vulnerable plugins
Stolen credentials
Abandoned plugins
Compromised hosting accounts
Exposed admin access
Another infected site under the same account

6. Recover reputation and search visibility

Some infections continue causing problems even after the server is clean.

Examples include:

Indexed Japanese SEO spam
Google Safe Browsing warnings
Search Console security issues
Spam URLs remaining in search results
Domain reputation problems

7. Monitor after cleanup

A successful cleanup is not:

“The scanner says zero malware.”

A better standard is:

“The malicious components are gone, the persistence paths are gone, the likely entry point has been addressed, and the site remains clean afterward.”

I turned this workflow into a book

After working on WordPress malware cleanup for years, I started documenting the process I use across real cases.

That eventually became:

WordPress Malware Removal for Developers & Site Owners

It covers areas including:

Diagnosing compromised WordPress sites
Determining infection scope
File-system cleanup
Database malware
Redirect malware
SEO spam
Fake plugins and themes
Hidden administrator accounts
Persistence and reinfection
Hosting and server issues
Blacklist recovery
Post-cleanup monitoring

The focus is on practical investigation rather than simply installing another security plugin.

The book is currently available using a Pay What You Want model, starting at $9.99:

https://www.mdpabel.com/books/wordpress-malware-removal/?utm_source=devto&utm_medium=article&utm_campaign=book_promo&utm_content=malware_layers

Final thought

When cleaning a hacked WordPress site, do not stop after finding the first malicious file.

The more useful question is:

What else must still exist for this infection to come back?

Finding that answer is often where the real malware removal work begins.

Suggested DEV tags: wordpress, security, cybersecurity, webdev

I’m Writing a Practical WordPress Malware Removal Book Based on Real Cleanup Cases

MD Pabel — Sat, 29 Aug 2026 19:58:48 +0000

I’m Writing a Practical WordPress Malware Removal Book Based on Real Cleanup Cases

A WordPress site can look completely normal to the owner while visitors are being redirected somewhere else.

A blank screen can be malware.

It can also be an ordinary PHP error.

A security scanner can find a suspicious file without telling you how it got there, what created it, or whether deleting it actually solved the compromise.

These are some of the reasons I started writing:

WordPress Malware Removal for Developers & Site Owners

The book is now available in Early Access on Leanpub, with Chapter 1 available as a free sample.

Why I’m Writing This Book

I’ve been working with WordPress sites since 2018 through freelance marketplaces, agencies, direct client projects, and my own company, 3Zero Digital.

During that time, I’ve investigated and cleaned more than 4,500 hacked WordPress sites.

The incidents were rarely as simple as:

Run a malware scanner → delete the infected file → change the password → done.

Real cases are usually messier.

I’ve worked on sites where:

desktop visitors saw a normal website while mobile visitors were redirected
malware was stored in the WordPress database rather than an obvious PHP file
administrators existed in the database but were hidden from the WordPress Users screen
fake plugins were designed to look harmless
SEO spam appeared in Google without being obvious inside WordPress
malicious behavior came back after the first cleanup
checkout pages loaded suspicious remote code
the WordPress files looked clean while the problem existed at the hosting, DNS, or CDN layer

That experience shaped the main idea behind the book:

Finding malware is not the same as understanding what happened.

Start With the Symptom, Not the Word “Malware”

One of the first lessons in the book is simple:

“Hacked” is a conclusion. The symptom is what you actually observed.

For example:

the site redirects
the screen is blank
Google shows pages you never created
an administrator is missing
checkout suddenly behaves differently
a visitor gets a warning
a deleted infection keeps returning

Each symptom may have a security explanation.

But many of them can also have ordinary explanations.

A blank page could be caused by malicious code replacing index.php.

Or it could be caused by a PHP/theme mistake.

The symptom alone does not decide which one is true.

Evidence does.

A Site Looking Normal Does Not Prove It Is Clean

One of the real cases used in Chapter 1 involved a website that appeared completely normal from the owner's desktop.

But a request using a mobile browser identity received a redirect to an external domain.

The malicious rule was checking the visitor before deciding what response to send.

That means checking the homepage once from your normal browser is a very weak security test.

A compromised site may behave differently depending on:

mobile vs desktop
logged-in vs logged-out users
first visit vs returning visit
direct traffic vs Google traffic
cookies
referrer
IP or geographic conditions

This is why WordPress malware investigation often requires looking beyond the WordPress dashboard.

What the Book Covers

The current plan includes 16 chapters:

Is the WordPress Site Actually Hacked?
How Does a WordPress Site Get Hacked?
What to Do Before Cleaning Malware
Find What Else Is Infected
Remove Malware from WordPress Files
Remove Malware from the WordPress Database
Clean the Hosting Account, Server, and DNS
Find and Remove WordPress Redirect Malware
Remove WordPress SEO Spam and Hacked URLs From Google
Find and Remove Fake WordPress Plugins and Themes
Remove Unwanted and Hidden WordPress Administrators
Find and Remove WooCommerce Credit-Card Skimming Malware
Hosting and Domain Suspension Removal
Blacklist Removal
Stop Malware from Coming Back
Secure and Monitor a Recovered Site

The goal is to follow an incident from the first suspicious symptom through investigation, cleanup, recovery, and verification.

This Is Not Meant to Be a Theory-Only Security Book

I’m trying to keep the book practical.

The examples come from real cleanup and investigation experience.

That includes looking at:

WordPress files
plugins and themes
database records
users and capabilities
browser source and Network requests
logs
cron jobs
hosting accounts
DNS and CDN settings
Google search results
WooCommerce checkout behavior

I also try to separate what the evidence proves from what it only suggests.

For example:

A suspicious loader contacting a remote server is evidence of suspicious behavior.

It is not automatically proof that payment information was stolen.

A malicious file proves that malicious code exists.

It does not automatically prove how the attacker originally entered the site.

Those distinctions matter during real incident response.

Early Access

The book is being published progressively on Leanpub.

Chapter 1 is available now as a free sample, and new chapters will be added as they are completed.

Early Access readers receive future chapters and updates to the same edition as they are released.

You can read the free sample or follow the book here:

https://www.mdpabel.com/books/wordpress-malware-removal/?utm_source=devto&utm_medium=article&utm_campaign=book_promo&utm_content=malware_layers

I’m also interested in feedback from WordPress developers, hosting professionals, security researchers, and site owners who have dealt with compromised WordPress sites.

What part of WordPress malware cleanup do you think causes the most confusion?

wordpress #security #webdev #cybersecurity

WordPress Malware Removal for Developers & Site Owners — Built from Real Cleanup Cases

MD Pabel — Mon, 17 Aug 2026 21:46:34 +0000

I’m Writing a Practical WordPress Malware Removal Book Based on Real Cleanup Cases

A WordPress site can look completely normal to the owner while visitors are being redirected somewhere else.

A blank screen can be malware.

It can also be an ordinary PHP error.

A security scanner can find a suspicious file without telling you how it got there, what created it, or whether deleting it actually solved the compromise.

These are some of the reasons I started writing:

WordPress Malware Removal for Developers & Site Owners

The book is now available in Early Access on Leanpub, with Chapter 1 available as a free sample.

Why I’m Writing This Book

I’ve been working with WordPress sites since 2018 through freelance marketplaces, agencies, direct client projects, and my own company, 3Zero Digital.

During that time, I’ve investigated and cleaned more than 4,500 hacked WordPress sites.

The incidents were rarely as simple as:

Run a malware scanner → delete the infected file → change the password → done.

Real cases are usually messier.

I’ve worked on sites where:

desktop visitors saw a normal website while mobile visitors were redirected
malware was stored in the WordPress database rather than an obvious PHP file
administrators existed in the database but were hidden from the WordPress Users screen
fake plugins were designed to look harmless
SEO spam appeared in Google without being obvious inside WordPress
malicious behavior came back after the first cleanup
checkout pages loaded suspicious remote code
the WordPress files looked clean while the problem existed at the hosting, DNS, or CDN layer

That experience shaped the main idea behind the book:

Finding malware is not the same as understanding what happened.

Start With the Symptom, Not the Word “Malware”

One of the first lessons in the book is simple:

“Hacked” is a conclusion. The symptom is what you actually observed.

For example:

the site redirects
the screen is blank
Google shows pages you never created
an administrator is missing
checkout suddenly behaves differently
a visitor gets a warning
a deleted infection keeps returning

Each symptom may have a security explanation.

But many of them can also have ordinary explanations.

A blank page could be caused by malicious code replacing index.php.

Or it could be caused by a PHP or theme mistake.

The symptom alone does not decide which one is true.

Evidence does.

A Site Looking Normal Does Not Prove It Is Clean

One of the real cases used in Chapter 1 involved a website that appeared completely normal from the owner's desktop.

But a request using a mobile browser identity received a redirect to an external domain.

The malicious rule was checking the visitor before deciding what response to send.

That means checking the homepage once from your normal browser is a very weak security test.

A compromised site may behave differently depending on:

mobile vs desktop
logged-in vs logged-out users
first visit vs returning visit
direct traffic vs Google traffic
cookies
referrer
IP or geographic conditions

This is why WordPress malware investigation often requires looking beyond the WordPress dashboard.

What’s Inside the Book

The current plan includes 16 chapters:

Is the WordPress Site Actually Hacked?
How Does a WordPress Site Get Hacked?
What to Do Before Cleaning Malware
Find What Else Is Infected
Remove Malware from WordPress Files
Remove Malware from the WordPress Database
Clean the Hosting Account, Server, and DNS
Find and Remove WordPress Redirect Malware
Remove WordPress SEO Spam and Hacked URLs From Google
Find and Remove Fake WordPress Plugins and Themes
Remove Unwanted and Hidden WordPress Administrators
Find and Remove WooCommerce Credit-Card Skimming Malware
Hosting and Domain Suspension Removal
Blacklist Removal
Stop Malware from Coming Back
Secure and Monitor a Recovered Site

The goal is to follow an incident from the first suspicious symptom through investigation, cleanup, recovery, and verification.

This Is Not a Theory-Only Security Book

The book is built from real WordPress malware cleanup cases and investigation experience.

The examples include work across:

WordPress files
plugins and themes
database records
users and capabilities
browser source and Network requests
logs
cron jobs
hosting accounts
DNS and CDN settings
Google search results
WooCommerce checkout behavior

I also try to separate what the evidence proves from what it only suggests.

For example, a suspicious loader contacting a remote server is evidence of suspicious behavior.

It is not automatically proof that payment information was stolen.

A malicious file proves that malicious code exists.

It does not automatically prove how the attacker originally entered the site.

Those distinctions matter during a real investigation.

Early Access

The book is being published progressively on Leanpub.

Chapter 1 is available now as a free sample.

Early Access readers buy once and receive the future chapters and updates to this edition as they are released.

📖 Read Chapter 1 free or get Early Access:

https://leanpub.com/wordpressmalwareremovalfordeveloperssiteowners

I’d also love to hear from WordPress developers, hosting professionals, security researchers, and site owners:

What part of WordPress malware cleanup causes the most confusion for you?

Why I’m Writing a Practical WordPress Malware Removal Book

MD Pabel — Fri, 14 Aug 2026 21:56:26 +0000

When a WordPress site gets hacked, one of the first recommendations is usually:

run a malware scanner,
reinstall WordPress,
update plugins,
change passwords,
and install a security plugin.

Those steps can be useful.

But after working on real compromised WordPress sites, I kept seeing incidents that did not fit neatly into that checklist.

A site could look completely normal on desktop while mobile visitors were redirected to spam.

A malware scanner could report nothing while malicious JavaScript was stored inside the WordPress database.

The WordPress Users screen could show one administrator while another privileged account was hidden by malicious code.

A clean-looking plugin could be legitimate software but still contain an unauthorized code snippet stored through its database settings.

And sometimes the WordPress files were clean because the real problem was outside WordPress entirely—in the server, DNS, CDN, or hosting account.

That is why I started writing WordPress Malware Removal for Developers & Site Owners.

It is a practical, evidence-led field guide built around real malware cleanup cases.

Why I Wanted to Write This Book

There is already a huge amount of WordPress security information online.

The problem is that a lot of malware-removal content stops at detection.

You are shown suspicious files, common malware signatures, security plugins, or a list of folders to check.

But in a real investigation, finding a suspicious file is often only the beginning.

You still need to answer questions like:

Is this file actually malicious?
What caused the behavior the visitor reported?
Is the malware stored in a file or in the database?
Why does the redirect appear only on mobile devices?
Why did the malware return after it was deleted?
Is an unfamiliar administrator actually unauthorized?
Is a plugin fake, modified, or simply custom?
Did a checkout script actually steal card data, or do we only have evidence that it could?
Did the attacker enter through WordPress at all?
What else needs to be cleaned before the site can be trusted again?

Those are the questions I wanted the book to focus on.

The goal is not to teach readers to search for scary-looking PHP functions.

The goal is to teach them how to follow the evidence.

WordPress Malware Removal Is More Than Cleaning Files

One of the main ideas in the book is that a hacked WordPress site has several different layers.

Malware may exist in:

WordPress core files,
plugins,
themes,
mu-plugins,
uploaded or hidden PHP files,
the WordPress database,
user accounts and permissions,
scheduled tasks,
server configuration,
hosting accounts,
DNS records,
CDN rules,
or another website sharing the same hosting environment.

That is why simply deleting the first malicious file you find can fail.

The file may only be the visible payload.

Something else may still be able to recreate it.

Real Cases Instead of Generic Malware Examples

A large part of the book is based on real cleanup and research cases.

The examples are used to explain how an investigation develops—not just to show screenshots of malicious code.

Conditional WordPress Redirect Malware

In one case, the site owner could browse the website normally from a desktop computer.

Visitors using phones were redirected elsewhere.

The difference turned out to matter more than the first malware scan.

The malicious rule checked the visitor's device before deciding whether to redirect them.

That case became part of the chapter on finding and removing WordPress redirect malware.

Malware Hidden in the WordPress Database

WordPress malware does not have to exist as a .php file.

Scripts, redirects, spam, malicious snippets, and other unauthorized values can be stored in normal WordPress database records.

The book covers how to search the database, identify which WordPress feature owns a suspicious value, and decide whether it should be repaired or removed without destroying legitimate site data.

Hidden WordPress Administrators

One investigation contained an administrator account that existed in the database but did not appear normally in the WordPress Dashboard.

Malicious code altered the user query and displayed counts so the account was harder to notice.

This is why one of the recurring lessons in the book is:

Do not let one WordPress screen become your only source of truth.

The hidden-administrator chapter follows the account through the database, the code hiding it, its permissions, sessions, and the cleanup process.

Fake Plugins and Hidden Backdoors

Attackers do not always create files with obvious names.

A malicious plugin may use a believable name, description, author, and version number.

It may even remove itself from the normal Plugins screen.

The book shows how to compare what WordPress displays with what actually exists in the filesystem, verify plugin identities against trusted sources, and investigate suspicious behavior before deleting anything.

Checkout Skimmers and Payment-Page Malware

E-commerce compromises require extra care.

A suspicious script appearing on a WooCommerce checkout page can have much more serious consequences than the same script appearing on an ordinary blog page.

The book includes a real investigation involving a checkout-targeted remote JavaScript loader.

But there is an important distinction:

The evidence showed that remote code could run on the checkout page.

The retained evidence did not prove that credit-card data had actually been stolen.

That difference matters.

A security investigation should say what the evidence supports—not what makes the most dramatic headline.

SEO Spam and Hacked URLs

Another common WordPress compromise appears through search engines rather than the visible website.

A site owner may see:

casino pages,
pharmaceutical keywords,
Japanese product spam,
unfamiliar indexed URLs,
or Search Console traffic for topics completely unrelated to the business.

Removing the spam from WordPress is only part of the recovery.

The book also looks at how those URLs remain visible in search engines and how to verify what the compromised site is still serving.

Server, DNS, and CDN Compromise

Sometimes repeatedly scanning WordPress will never find the problem.

In one type of incident, visitors may be reaching the wrong server because a DNS record was changed.

A CDN rule, hosting redirect, server configuration, or compromised hosting account can also affect what visitors receive before WordPress has a chance to run.

That is why the book does not treat WordPress as an isolated application.

Malware That Keeps Coming Back

Reinfection is one of the most frustrating WordPress malware problems.

A site gets cleaned.

The malicious file disappears.

Then it comes back.

Instead of repeatedly deleting the same payload, the investigation has to find what can restore it:

another malicious file,
a hidden plugin,
a scheduled task,
a compromised account,
another infected website,
a database value,
or something outside WordPress.

The book treats recurrence as evidence.

A Site Can Look Hacked Without Being Hacked

The opposite lesson matters too.

Not every WordPress error is malware.

A blank page can come from:

a PHP error,
a plugin conflict,
a broken theme,
a failed update,
a memory problem,
or a normal coding mistake.

In one real case, a WordPress site showed a white screen because of a problem in the active theme's functions.php.

In another case, an almost identical blank site had a compromised root index.php containing malicious loader behavior.

Same symptom.

Two completely different conclusions.

That is why the first chapter of the book begins with a simple principle:

Start with the symptom, not the word “malware.”

What the Book Covers

The current book includes chapters on topics such as:

identifying whether a WordPress site is actually hacked,
understanding how WordPress sites get compromised,
preparing safely before malware cleanup,
finding connected infections,
cleaning WordPress core, plugins, and themes,
removing malware from the WordPress database,
cleaning users and WordPress state,
investigating hosting, server, DNS, and CDN problems,
finding and removing WordPress redirect malware,
removing SEO spam and hacked URLs,
detecting fake plugins, themes, and hidden backdoors,
removing hidden WordPress administrators,
investigating checkout skimmers and payment-page malware,
and handling malware that returns after cleanup.

More chapters are still being developed.

Who This Book Is For

I am writing it primarily for:

WordPress developers,
freelancers,
site owners,
agency teams,
hosting and technical-support staff,
and people who want to understand WordPress malware cleanup beyond automated scanners.

It is not meant to turn every reader into a malware analyst overnight.

Instead, I want readers to understand why a cleanup step is being performed and what evidence should support it.

The Book Is Still Under Development

WordPress Malware Removal for Developers & Site Owners is currently an early-access work in progress.

The first chapter is already available as a free preview:

📘 Read Chapter 1 Free

Is the WordPress Site Actually Hacked?

👉 Read the free chapter and join the book waitlist

The first chapter looks at mobile-only redirects, blank pages, browser evidence, scanners, hidden administrators, search-engine clues, logs, DNS, and the difference between a suspicious symptom and confirmed compromise.

One Principle I Want the Book to Keep

If I had to reduce the entire project to one idea, it would probably be this:

Finding malware is not the same as understanding the compromise.

A malicious file tells you that a malicious file exists.

A database injection tells you that an unauthorized value was stored.

A hidden administrator tells you that unauthorized access exists.

None of those observations automatically proves how the attacker first entered, what else they changed, or whether they still have another way back in.

That is the investigation the rest of the book is about.

WordPress Malware Removal for Developers & Site Owners is currently under development. New chapters and case studies will be added as the manuscript progresses.

How to Check Whether a WordPress Plugin or Theme Version Is Vulnerable

MD Pabel — Tue, 04 Aug 2026 20:57:53 +0000

A WordPress plugin may have published vulnerabilities, but that does not mean every version of the plugin is affected.

The installed version matters.

For example, a vulnerability may affect:

All versions up to and including 2.8.7

If your website uses version 2.8.8, that specific vulnerability may already be patched.

The problem is that many WordPress site owners do not know how to compare their installed versions with documented affected-version ranges.

That is why I built the 3Zero WordPress Vulnerability Checker.

What the checker does

The tool lets you check:

WordPress plugins
WordPress themes
WordPress core

Enter the software name and your installed version.

The checker compares it with documented affected-version ranges in our synchronized vulnerability database.

The system currently includes:

23 years of WordPress vulnerability data
Vulnerability records covering 18,044 WordPress plugins and themes
WordPress core vulnerability records

Nothing is installed on your website.

The tool does not connect to your WordPress dashboard or scan your server. You only enter the software name and version.

Try the checker

Check your WordPress plugin, theme, or core version

How to find your installed version

Plugin version

Open:

WordPress Dashboard
→ Plugins
→ Installed Plugins

The installed version normally appears beside the plugin name.

Theme version

Open:

WordPress Dashboard
→ Appearance
→ Themes

Select the active or installed theme to view its version.

WordPress core version

Open:

WordPress Dashboard
→ Dashboard
→ Updates

You can also find the WordPress version in the At a Glance dashboard panel.

What an affected-version match means

A match means the version you entered falls inside a documented affected-version range.

The result may show:

Vulnerability title
Severity
CVSS score
Affected version range
Known patched version
Publication date
Original source record

For example:

Installed version: 2.8.7
Affected-version match: Yes
Known patched version: 2.8.8 or later

A vulnerable version does not mean the website is hacked

This is an important difference.

A vulnerable version shows that a documented security weakness may have existed in the installed software.

It does not prove that:

An attacker used the vulnerability
Malware is present
The website was compromised
The vulnerable component was the original entry point

Confirming an actual incident requires evidence from the website, database, server, user accounts, and available logs.

What should you do after finding a match?

First, check whether a patched version is available.

Create a reliable backup and update the affected plugin, theme, or WordPress core.

Depending on the vulnerability type and the website's behaviour, you may also need to review:

Unknown administrator accounts
Recent user-role changes
Suspicious or recently modified files
Unexpected scheduled tasks
Modified database values
Active login sessions
Unfamiliar redirects
Injected pages or scripts

Updating closes the known vulnerability.

However, it does not automatically remove changes an attacker may have made before the update.

What does “no match found” mean?

A no-match result means the entered version did not match an affected-version range currently available in the synchronized dataset.

It does not guarantee that:

The software has no security issues
The website is completely secure
The website contains no malware
Every possible vulnerability has been documented

The tool answers one specific question:

Does this installed version match a documented affected-version range?

It is a version checker, not a complete malware scanner or website security audit.

Who can use this tool?

The checker may be useful for:

WordPress site owners
Freelance developers
Website maintenance providers
WordPress agencies
Hosting support teams
Security professionals

It can help you identify which installed software versions may need faster attention.

Check your WordPress software

Use the free checker here:

3Zero WordPress Vulnerability Checker

Vulnerability data: Wordfence Intelligence

Version matching, presentation, and analysis: 3Zero Digital

How to Investigate WordPress ?p=, ?q=, and ?a= SEO Spam URLs

MD Pabel — Mon, 20 Jul 2026 08:15:34 +0000

During a WordPress SEO spam investigation, I found Google requesting URLs like these:

https://example.com/?p=23932
https://example.com/?q=98237492
https://example.com/?a=739284729

At first, they look similar: a short query parameter followed by a large number.

But they should not all be treated the same way.

The most dangerous mistake would be to create a rule that blocks every single-letter query parameter.

That could break:

Real WordPress posts
Internal searches
Plugin filters
Tracking parameters
Form submissions
Application features

In a larger cleanup involving approximately 242,000 unwanted URL variations, I had to separate legitimate WordPress behaviour from malicious URL patterns.

The full incident is documented in my spam URL removal case study. This article focuses on query-string analysis.

What is a query string?

A query string is the part of a URL following the question mark.

Example:

https://example.com/?p=123

The query string is:

p=123

Multiple parameters can be separated with an ampersand:

https://example.com/?page=2&sort=price

Query strings are normal.

Their existence does not mean a website is hacked.

The issue begins when malware generates large numbers of meaningless or spam-producing variations.

Why `?p=` can be legitimate

WordPress uses the p parameter to request a post by its database ID.

For example:

https://example.com/?p=123

If post ID 123 exists, WordPress may redirect the request to its normal permalink:

https://example.com/example-post/

Therefore, this rule would be unsafe:

RewriteCond %{QUERY_STRING} (^|&)p=[0-9]+(&|$) [NC]
RewriteRule ^ - [G,L]

It would block every WordPress post query URL.

Even when the site uses pretty permalinks, old links or external sites may still reference the ?p= version.

How `?p=` was abused in the incident

The hacked website produced many URLs in a narrow numerical range:

/?p=23981
/?p=23932
/?p=23919
/?p=23916
/?p=23860
/?p=23795
/?p=23783

Before blocking the range, I checked whether those IDs belonged to real posts.

A database query can help:

SELECT ID, post_title, post_type, post_status
FROM wp_posts
WHERE ID BETWEEN 23000 AND 24999
ORDER BY ID ASC;

If legitimate records exist, a broad range rule may not be appropriate.

You may need to:

Exclude known IDs
Match another part of the request
Handle the response in PHP
Use a smaller numerical range
Avoid blocking the pattern entirely

`?q=` may also be legitimate

The q parameter is not WordPress’s default search parameter, but plugins and custom applications may use it.

Examples include:

Search plugins
Product filters
Documentation systems
External integrations
Analytics tools

Never assume ?q= is malicious simply because it appears in spam examples.

Verify:

Does the legitimate site use it?
What response does a normal ?q= request produce?
Is the suspicious value always numerical?
Does the spam use a consistent length or range?
Do logs show a common user agent or referrer?
Does the pattern appear in Google Search Console?

`?a=` and other single-letter parameters

Attackers sometimes generate many variants by changing the parameter name:

/?a=839472938
/?b=739284729
/?x=193847293

A tempting firewall rule is:

RewriteCond %{QUERY_STRING} (^|&)[a-z]=[0-9]+(&|$) [NC]
RewriteRule ^ - [G,L]

That is extremely broad.

It may block legitimate features that use parameters like:

?s=wordpress
?p=123
?m=202607

Pattern matching should be evidence-driven.

Collect URLs before blocking them

I combined URLs from several sources:

Google Search Console Pages report
Search performance exports
Server access logs
Google search results
Malicious sitemap files
Security scanner reports

The URLs were saved in a CSV file for analysis.

A simple CSV might look like:

URL
https://example.com/?a=839472938
https://example.com/?q=739284729
https://example.com/?p=23932
https://example.com/real-page/

Filter the domain with Python

import pandas as pd

INPUT_FILE = "urls.csv"
OUTPUT_FILE = "domain-urls.csv"
SITE_URL = "https://example.com"

df = pd.read_csv(INPUT_FILE)

if "URL" not in df.columns:
    raise ValueError("The CSV must contain a column named URL.")

urls = df["URL"].fillna("").astype(str)

domain_urls = df[urls.str.startswith(SITE_URL)].copy()
domain_urls.to_csv(OUTPUT_FILE, index=False)

print(f"Saved {len(domain_urls)} URLs to {OUTPUT_FILE}")

Extract query parameters

Python’s standard library can separate parameter names and values safely:

import pandas as pd
from urllib.parse import urlparse, parse_qs

INPUT_FILE = "domain-urls.csv"
OUTPUT_FILE = "query-parameters.csv"

df = pd.read_csv(INPUT_FILE)

rows = []

for url in df["URL"].fillna("").astype(str):
    parsed = urlparse(url)
    parameters = parse_qs(parsed.query, keep_blank_values=True)

    for name, values in parameters.items():
        for value in values:
            rows.append(
                {
                    "url": url,
                    "path": parsed.path,
                    "parameter": name,
                    "value": value,
                    "value_length": len(value),
                    "numeric": value.isdigit(),
                }
            )

result = pd.DataFrame(rows)
result.to_csv(OUTPUT_FILE, index=False)

print(f"Saved {len(result)} parameter rows to {OUTPUT_FILE}")

This makes it easier to answer questions such as:

Which parameter appears most often?
Are the values always numbers?
What is the usual value length?
Are the values concentrated in one range?
Do different parameters generate the same content?

Count the patterns

import pandas as pd

df = pd.read_csv("query-parameters.csv")

summary = (
    df.groupby(["parameter", "numeric"])
      .size()
      .reset_index(name="count")
      .sort_values("count", ascending=False)
)

print(summary.to_string(index=False))

Example output:

parameter  numeric  count
a          True     8421
q          True     6138
p          True     1820
s          False      42

This does not prove that a, q, or p are malicious.

It identifies where to investigate.

Review the server response

Test several examples:

curl -I "https://example.com/?a=839472938"
curl -I "https://example.com/?q=739284729"
curl -I "https://example.com/?p=23932"

Check whether they return:

A hacked URL returning 200 is especially important because Google may treat it as a real page.

Also inspect the body:

curl -s "https://example.com/?a=839472938" | head -n 40

Compare normal and suspicious requests.

Check access logs

Useful questions include:

Is Googlebot requesting the URLs?
Are other bots requesting the same patterns?
How often are they requested?
Do they reach index.php?
Are they producing expensive application responses?
Did the requests continue after malware removal?

Example Apache log searches:

grep -E '\?(a|q|p)=[0-9]+' access.log | head

Count matching requests:

grep -Ec '\?(a|q|p)=[0-9]+' access.log

View the most common URLs:

grep -E '\?(a|q|p)=[0-9]+' access.log \
  | awk '{print $7}' \
  | sort \
  | uniq -c \
  | sort -nr \
  | head -n 30

Log formats differ, so the URL may not always be in field seven.

Build the narrowest possible rule

Suppose the investigation confirms:

a and q are not used legitimately
Their spam values always contain at least eight digits
Requests should never return content again

A narrow Apache rule could be:

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{QUERY_STRING} (^|&)(?:a|q)=[0-9]{8,}(&|$) [NC]
RewriteRule ^ - [G,L]

</IfModule>

This returns 410 Gone.

It does not block:

?s=wordpress
?p=123
?q=shoes
?a=42

Whether those exclusions are correct depends on the actual website.

Handle a confirmed `?p=` range separately

If a numerical range has been verified as malicious and contains no legitimate WordPress records:

# Example range only: p=23000 through p=24999
RewriteCond %{QUERY_STRING} (^|&)p=2[3-4][0-9]{3}(&|$) [NC]
RewriteRule ^ - [G,L]

This is safer than blocking every post ID, but it still needs testing.

Test both malicious and legitimate cases

Spam tests:

curl -I "https://example.com/?a=12345678"
curl -I "https://example.com/?q=987654321"
curl -I "https://example.com/?p=23932"

Legitimate tests:

curl -I "https://example.com/?s=security"
curl -I "https://example.com/?p=123"
curl -I "https://example.com/"
curl -I "https://example.com/wp-login.php"

A successful spam response should look like:

HTTP/2 410

The legitimate URLs should keep their expected behaviour.

Why server-level handling matters

If WordPress handles every request, even a missing page can require:

PHP startup
WordPress bootstrap
Plugin loading
Database queries
Theme rendering

A narrow Apache rule can stop confirmed spam requests earlier.

That reduces unnecessary application work while also providing a clear status to search engines.

Do not treat query patterns as malware signatures

A URL such as:

/?q=12345678

is not automatically proof of malware.

Context matters.

The evidence should include some combination of:

Unwanted content
Unexpected HTTP 200 responses
Search Console impressions
Large-scale repeated patterns
Malicious files or database content
Access-log activity
Unknown sitemap entries

The rule should be the result of the investigation, not the beginning of it.

Final checklist

Before blocking query-string spam:

Export representative URLs
Group them by parameter and structure
Confirm whether the parameter is used legitimately
Check database IDs for ?p=
Test current HTTP responses
Inspect server logs
Create the narrowest rule possible
Test legitimate pages after deployment
Monitor 410 responses
Keep the patterns out of the canonical sitemap

The larger lesson is simple:

Do not block thousands of URLs individually when a small number of verified patterns explains them.

The full cleanup—including malware removal, Google Search Console requests, 410 handling, and sitemap recovery—is available in my complete WordPress SEO spam case study.

Why Cleaning WordPress Malware Does Not Remove Spam Pages From Google

MD Pabel — Mon, 20 Jul 2026 08:15:13 +0000

A website can be malware-free today while Google continues showing hacked pages for weeks or months.

This confuses many website owners.

They clean the WordPress installation, run another malware scan, open the homepage, and see that everything looks normal.

Then they search Google and find:

Japanese product titles
Gambling pages
Pharmaceutical keywords
URLs they never created
Content that is not visible in WordPress
Random parameters such as ?p=23932 or ?q=98237492

The natural reaction is:

If the malware is gone, why is Google still showing the spam?

Because malware cleanup and Google index cleanup are two different processes.

I recently handled a case involving approximately 242,000 unwanted URL variations. The complete investigation is available in my WordPress SEO spam recovery case study.

Here is the most important lesson from that cleanup.

Problem one: the hacked website

The first problem exists on the server.

The attacker may have added:

Malicious PHP files
Backdoors
Fake plugins
Hidden administrator users
Database injections
Modified .htaccess rules
Malicious cron events
PHP files inside the uploads directory
Scripts that fetch spam from an external server

This is the active security incident.

Until it is fixed, the website may continue producing new spam URLs.

Problem two: Google already knows the URLs

The second problem exists in Google’s crawl and index systems.

Google may have already discovered the hacked URLs through:

Internal links created by malware
Malicious XML sitemaps
External spam links
Generated archive pages
Search-engine cloaking
Previous crawls of the infected site

Cleaning the malicious code does not erase Google’s memory of those URLs.

Google needs to revisit them and receive an appropriate signal.

That signal may be:

404 Not Found
410 Gone
A legitimate redirect to a relevant replacement
A valid noindex response in cases where the page still exists

For completely fake hacked URLs, I normally prefer 404 or 410 rather than redirecting everything to the homepage.

Why the website can look normal

SEO spam often does not affect every visitor equally.

Malicious code may change its response based on:

User agent
Referrer
Cookie
IP address
Device
Search-engine crawler
Requested URL pattern

For example, the owner may open:

https://example.com/

and see the real homepage.

Googlebot may request:

https://example.com/jp/fake-product/

and receive a generated product page.

The owner may never see that route inside WordPress admin because the page does not exist as a normal post.

It may be dynamically generated by PHP.

Why fake product pages appear

Japanese keyword hacks commonly promote products through compromised domains.

A hacked result may contain:

Japanese product names
Prices
Review text
Shopping descriptions
Product structured data
Unrelated images

The website may not sell any of those products.

The attacker is borrowing the domain’s reputation and crawl history.

This is why searching only the WordPress Posts screen is not a complete investigation.

Step 1: stop new spam from being created

I always begin with the server and application.

The investigation normally includes:

Comparing WordPress core files with clean originals
Checking plugins, themes, and must-use plugins
Inspecting root and nested .htaccess files
Searching the database
Reviewing WordPress administrators
Checking scheduled tasks
Examining access logs
Rotating compromised credentials

The site should not be considered clean simply because one scanner reports no malware.

Scanners are helpful, but manual investigation is often needed to find persistence mechanisms.

Step 2: collect examples of the hacked URLs

After stopping the infection, I collect URLs from multiple sources.

Google searches

site:example.com
site:example.com inurl:jp
site:example.com filetype:html
site:example.com casino

These searches do not provide an exact index count, but they can reveal visible patterns.

Google Search Console

Useful reports include:

Indexing → Pages
Performance → Search results
Security Issues
Manual Actions
Sitemaps

Server logs

Logs can reveal URLs that bots continue requesting even when they no longer appear prominently in Search Console.

Search Analytics API

The API can help export pages and queries that received impressions.

It is useful performance data, but it should not be treated as a complete list of every URL Google knows.

Step 3: look for patterns, not individual URLs

The incident I investigated included patterns like:

/?a=839472938
/?q=739284729
/?p=23932
/pages/random-product.html
/jp/fake-category/
/products/23860

Removing these one by one would not scale.

Instead, I grouped them by:

Directory
Query parameter
Numerical range
File extension
Spam keyword
URL structure

A few repeatable patterns explained a large part of the 242,000 URL variations.

Step 4: return a real removal status

Once a pattern was confirmed to be malicious, the server returned 410 Gone before WordPress loaded.

A simplified Apache example:

ErrorDocument 410 "<h1>410 Gone</h1><p>This spam URL has been permanently removed.</p>"

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{QUERY_STRING} (^|&)(?:a|q)=[0-9]{5,}(&|$) [NC]
RewriteRule ^ - [G,L]

RewriteRule ^(?:pages|jp)(?:/|$) - [G,L,NC]
RewriteRule ^products/[0-9]+(?:/|$) - [G,L,NC]

</IfModule>

These rules are examples, not universal signatures.

A rule must be based on patterns verified on the affected site.

Why I did not redirect everything to the homepage

A fake Japanese product page does not have a meaningful replacement on the website.

Redirecting it to the homepage would communicate that the unrelated resource moved there.

It may also result in soft-404 behaviour.

My general decision process is:

Relevant replacement exists: use 301
Resource never existed or no longer exists: use 404
Confirmed malicious resource deliberately removed: 410 can be appropriate
Page still exists but should not appear in search: consider noindex

The response should match what actually happened.

Step 5: use Search Console removals carefully

Google Search Console can temporarily hide urgent results.

For a single URL, submit a specific request.

For an entirely malicious directory, use:

Remove all URLs with this prefix

Examples:

https://example.com/jp/
https://example.com/pages/
https://example.com/products/

Do not submit a broad prefix if it includes legitimate pages.

Search Console removal is temporary. It does not replace the server response.

Step 6: submit a clean sitemap

After the cleanup, the normal sitemap should contain only URLs that should appear in Google.

That generally means:

Canonical URLs
HTTP 200 pages
Real content
Preferred HTTPS versions
Preferred hostname versions

It should not contain:

Hacked URLs
Redirects
404 pages
410 pages
Internal search pages
Random query parameters

The clean sitemap helps Google focus on the legitimate website structure.

Step 7: allow Google to recrawl the spam URLs

It can be tempting to block the hacked paths in robots.txt.

That can be counterproductive if Google needs to see their 404 or 410 response.

Googlebot should be able to request the URL and confirm that it is gone.

The spam URLs should be removed from the legitimate sitemap, but not hidden from the removal response.

How long does recovery take?

The malware cleanup and the Google cleanup do not follow the same timeline.

The security work may be completed quickly.

Google still needs to:

Revisit the affected URLs
Observe the new status
Process the changes
Update search results

The time varies based on:

Number of URLs
Crawl frequency
Internal and external links
Sitemap history
Server stability
Whether new spam continues appearing

This is why I avoid promising that hundreds of thousands of URLs will disappear immediately.

Signs that the recovery is working

I monitor:

Declining spam-query impressions
More hacked URLs reporting 404 or 410
Correct titles returning
Legitimate pages recovering visibility
Googlebot requesting the old spam paths
No new spam patterns
No returning malicious files
No new unauthorized users

An increase in reported 404 or 410 URLs is not always bad after a hack.

It may show that Google is revisiting the malicious URLs and receiving the intended response.

Final takeaway

A successful WordPress SEO spam cleanup has two parts:

Security recovery

Remove malware
Remove backdoors
Close the entry point
Secure accounts
Stop new URLs

Search recovery

Collect unwanted URLs
Identify patterns
Return 404 or 410
Use temporary removals when needed
Submit a clean sitemap
Monitor recrawling

Stopping after the malware scan leaves half the job unfinished.

The full investigation—including the URL patterns, .htaccess firewall, Search Console removals, and sitemap strategy—is documented in my complete 242,000-URL recovery case study.

How I Used 410 Gone Rules to Remove WordPress SEO Spam URLs

MD Pabel — Mon, 20 Jul 2026 08:14:42 +0000

A hacked WordPress website can be cleaned in a few hours, but the damage left in Google may remain much longer.

In one cleanup, the website looked normal when opened directly. Google Search showed something completely different:

Japanese product pages
Gambling-related URLs
Random numerical query parameters
Fake .html pages
Content the website owner had never published

Approximately 242,000 unwanted URL variations were associated with the incident.

Removing the malware stopped new pages from being generated, but Google already knew about many of the hacked URLs.

That created a second problem:

How do you permanently retire thousands of generated URLs without loading WordPress for every request?

My solution was to identify repeatable URL patterns and return 410 Gone at the Apache level.

I documented the complete malware and Google index recovery in this WordPress SEO spam cleanup case study. This article focuses specifically on the server-side implementation.

Why malware removal was not enough

Suppose malware creates URLs like these:

https://example.com/?a=839472938
https://example.com/?q=739284729
https://example.com/pages/fake-product.html
https://example.com/jp/random-product/
https://example.com/products/23932

After the malicious PHP is removed, those URLs may stop displaying spam.

But Googlebot, scrapers, security scanners, and other bots may continue requesting them for months.

Without a server-level rule, every request might still:

Start PHP
Load WordPress core
Load active plugins
Connect to MySQL
Run database queries
Load the theme
Generate a full 404 page

That is unnecessary work for URLs that should never exist again.

Why I chose 410 Gone

A 404 Not Found response means the server cannot find the requested resource.

A 410 Gone response means the resource was deliberately removed and is not expected to return.

Both statuses can eventually remove a URL from Google. I used 410 because these URLs were confirmed hacked resources that had no legitimate replacement.

The important requirements were:

The URL must not return HTTP 200
The response must not be a soft 404
Googlebot must be able to crawl the URL
The status must remain consistent
Legitimate pages must not match the rule

A 410 response is not an instant deindexing button. Google still needs to revisit and process the URL.

Identify patterns before writing rules

I did not write firewall rules based on one example URL.

I collected samples from:

Google Search Console
Google site: searches
Search Analytics API exports
Server access logs
Existing malicious sitemap files

The samples revealed several repeated structures.

Random query parameters

/?a=839472938
/?q=739284729
/?x=193847293

Hacked directories

/pages/fake-product.html
/jp/random-category/
/products/23932

Spam words inside paths

/online-casino-offer/
/poker-jackpot/
/viagra-product.html

Generated HTML pages

/random-folder/product-name.html
/pages/discount-item.html

The rules were based only on patterns confirmed on that particular website.

A case-specific Apache firewall

The following is a simplified example.

Do not copy it unchanged. Back up the existing .htaccess file and verify that every pattern is malicious on your own site.

Place the rules before the normal WordPress rewrite block.

# ----------------------------------------------------------------------
# CASE-SPECIFIC WORDPRESS SEO SPAM FIREWALL
# ----------------------------------------------------------------------

ErrorDocument 410 "<h1>410 Gone</h1><p>This hacked spam URL has been permanently removed.</p>"

<IfModule mod_rewrite.c>
RewriteEngine On

# --------------------------------------------------
# 1. CONFIRMED RANDOM QUERY PARAMETERS
# --------------------------------------------------

# Examples:
# ?a=12345678
# ?q=987654321

RewriteCond %{QUERY_STRING} (^|&)(?:a|q)=[0-9]{5,}(&|$) [NC]
RewriteRule ^ - [G,L]

# --------------------------------------------------
# 2. CONFIRMED MALICIOUS DIRECTORIES
# --------------------------------------------------

RewriteRule ^(?:pages|jp)(?:/|$) - [G,L,NC]
RewriteRule ^products/[0-9]+(?:/|$) - [G,L,NC]

# --------------------------------------------------
# 3. CONFIRMED SPAM WORDS IN THE PATH
# --------------------------------------------------

RewriteRule ^.*(?:casino|gambling|viagra|cialis|poker|baccarat|roulette|jackpot).*$ - [G,L,NC]

# --------------------------------------------------
# 4. OPTIONAL HTML RULE
# --------------------------------------------------

# Enable only when the legitimate website has no real .html URLs.
# RewriteRule ^.*\.html$ - [G,L,NC]

</IfModule>

Apache’s G flag returns HTTP 410 Gone.

The L flag stops further rewrite processing for the matching request.

Be extremely careful with WordPress `?p=` URLs

WordPress uses query URLs like this:

https://example.com/?p=123

That can be a legitimate post URL.

During the incident, some unwanted URLs also used the same structure:

/?p=23981
/?p=23932
/?p=23919

Blocking every ?p= request would have been dangerous.

Before creating a rule, I checked whether the suspicious ID range contained real WordPress content:

SELECT ID, post_title, post_status
FROM wp_posts
WHERE ID BETWEEN 23000 AND 24999
ORDER BY ID ASC;

Only after confirming the relevant range did not contain legitimate content could a narrow range rule be considered.

For example:

# Example only: matches p values from 23000 through 24999.
RewriteCond %{QUERY_STRING} (^|&)p=2[3-4][0-9]{3}(&|$) [NC]
RewriteRule ^ - [G,L]

A safer rule is always better than a broad one.

Test the rules with curl

I tested known spam URLs:

curl -I "https://example.com/?a=123456789"
curl -I "https://example.com/?q=987654321"
curl -I "https://example.com/pages/fake-product.html"
curl -I "https://example.com/jp/fake-category/"

The expected response was:

HTTP/2 410

I then tested legitimate areas:

curl -I "https://example.com/"
curl -I "https://example.com/wp-login.php"
curl -I "https://example.com/wp-admin/"
curl -I "https://example.com/?s=wordpress"
curl -I "https://example.com/?p=123"

Those URLs needed to continue returning their normal status or redirect.

Never assume a rewrite rule is safe because the syntax is valid.

How this reduced server usage

The firewall stopped matching requests before WordPress handled them.

That meant the server did not need to fully load:

WordPress core
Plugins
Theme files
Database queries
A styled 404 template

The benefit became noticeable because bots continued requesting old hacked URLs after the infection had been removed.

For a small rule set, .htaccess can be practical.

For a very large or high-traffic site, equivalent rules may be better placed in:

Apache virtual-host configuration
Nginx configuration
Cloudflare
A web application firewall
A custom application-level route handler

Do not block the URLs in robots.txt

Google must request a hacked URL to observe the 404 or 410 response.

If the URL is blocked in robots.txt, Googlebot may be unable to see that it has been permanently removed.

My approach was:

Remove spam URLs from the legitimate sitemap
Allow Googlebot to request them
Return 410 for confirmed malicious patterns
Monitor recrawling through logs and Search Console

Search Console removal is only temporary

I also used Google Search Console’s Removals tool for urgent suppression.

For dedicated hacked directories, the option Remove all URLs with this prefix was useful:

https://example.com/pages/
https://example.com/jp/
https://example.com/products/

However, Search Console removal is not the permanent fix.

The permanent fix was the combination of:

Malware removal
Consistent 410 responses
A clean sitemap
Continued monitoring

Final lesson

The site did not really have 242,000 separately created WordPress pages.

It had a smaller number of malicious patterns generating thousands of URL variations.

Once those patterns were identified, the recovery became manageable:

Clean the infection
Collect URL samples
Group them by structure
Confirm that the patterns are not legitimate
Return 410 before WordPress loads
Temporarily suppress urgent results
Monitor Googlebot and server logs

The full investigation, Search Console workflow, sitemap experiment, and malware-cleanup process are documented in my complete spam URL removal case study.

WP-VCD Malware in WordPress: How It Spreads, What It Breaks, and Why It Comes Back

MD Pabel — Fri, 17 Jul 2026 15:44:46 +0000

During a recent WordPress malware investigation, I found this code at the beginning of a plugin file:

<?php
if (file_exists(dirname( __FILE__ ) . '/class.plugin-modules.php')) {
    include_once(dirname( __FILE__ ) . '/class.plugin-modules.php');
}
?>

It is only one short line, and the rest of the file looked like normal plugin code.

But the referenced file name immediately stood out:

class.plugin-modules.php

This is a well-known indicator associated with WP-VCD , a WordPress malware campaign historically distributed through nulled or pirated plugins and themes.

The infected plugin in this particular case was old and inactive. However, the plugin name was not the most important finding. The same deployment method can appear inside many different premium plugins and themes downloaded from unofficial sources.

That is what makes WP-VCD dangerous: the nulled plugin or theme is often only the initial carrier. Once activated, the malware can copy itself into themes, modify WordPress core files, communicate with external servers and spread to other WordPress installations under the same hosting account.

Deleting the original plugin may therefore remove the source package while leaving the active infection behind.

What is WP-VCD malware?

WP-VCD is a WordPress malware family that became widely known between 2017 and 2019. It was distributed mainly through websites offering pirated versions of paid WordPress plugins and themes.

Instead of exploiting a vulnerability in WordPress, the campaign relied on site owners installing the malware themselves.

A user would search for a free copy of a premium theme or plugin, download a modified ZIP file and install it through WordPress. The package looked functional, but additional PHP files had been added before distribution.

Wordfence documented that WP-VCD packages commonly included either:

class.plugin-modules.php

or:

class.theme-modules.php

The legitimate plugin or theme was then modified so that the extra file executed when the software was activated. Wordfence also documented persistent backdoors, command-and-control communication, black-hat SEO activity and malicious advertising across infected sites. (Wordfence)

Although the campaign is old, old nulled packages are still present on websites, backups, staging installations and abandoned hosting accounts.

How to recognize the initial loader

A typical loader looks similar to this:

<?php
if (file_exists(dirname( __FILE__ ) . '/class.plugin-modules.php')) {
    include_once(dirname( __FILE__ ) . '/class.plugin-modules.php');
}
?>

A theme-based version may load:

class.theme-modules.php

The code itself performs three simple actions.

It identifies the current directory

dirname( __FILE__ )

This returns the directory containing the current PHP file.

It checks whether the deployer exists

file_exists(...)

The loader does not produce an error when the referenced file is missing.

It executes the deployer

include_once(...)

If the file exists, PHP loads and executes it.

This means the small line in functions.php is not the complete malware. It is only the entry point to a second file containing the installer or deployer.

The legitimate-looking structure is intentional. Wordfence noted that WP-VCD often avoided heavy obfuscation and instead hid behind ordinary filenames and code that could be overlooked during a quick inspection.

The carrier is not always the active infection

It helps to separate three parts of a WP-VCD compromise:

Carrier
   ↓
Deployer
   ↓
Persistent backdoors and remote payloads

The carrier

This is the nulled plugin or theme downloaded by the site owner.

It may still function exactly like the original premium product, making the package appear trustworthy.

The deployer

This is commonly:

class.plugin-modules.php

or:

class.theme-modules.php

Its job is to install the infection in other locations.

The persistent infection

After deployment, malicious code may continue running from theme files, WordPress core files or neighbouring WordPress installations.

This distinction explains why an inactive plugin may still be important evidence.

The plugin may no longer be executing, but it may identify how the compromise originally started.

How WP-VCD spreads after activation

Historical versions followed a multi-stage deployment process.

1. The nulled software is activated

The modified plugin or theme loads the added deployer file.

2. Installed themes are scanned

The deployer searches the site for WordPress themes.

3. Backdoor code is added to theme files

WP-VCD has been documented injecting code into the functions.php file of every installed theme, not only the active theme.

4. Modification times may be restored

After editing the files, some versions restored their previous modification timestamps. This made the files look older and reduced the usefulness of sorting by “Last Modified.”

5. The site is registered with command-and-control infrastructure

The malware can send information about the infected site to an attacker-controlled server.

6. Other WordPress installations are discovered

The deployer may move through the hosting directory structure and look for additional WordPress sites.

7. WordPress core is modified

Documented versions created:

/wp-includes/wp-vcd.php

and modified:

/wp-includes/post.php

so that wp-vcd.php executed during normal WordPress requests.

This created a persistent reinfection loop. If a backdoor was removed from a theme, wp-vcd.php could write it back during a later page request.

A simplified infection chain looks like this:

Nulled plugin or theme
        ↓
class.plugin-modules.php
or class.theme-modules.php
        ↓
Backdoors injected into theme functions.php files
        ↓
wp-includes/wp-vcd.php created
        ↓
wp-includes/post.php modified
        ↓
Remote instructions and additional payloads
        ↓
Other WordPress installations may be infected

A useful forensic clue: the deployer may remove its own installer

One of the more interesting WP-VCD behaviours is that the initial deployer may remove its installation code after it finishes spreading the malware.

The original class.plugin-modules.php or class.theme-modules.php file may therefore appear nearly empty when it is discovered later.

Wordfence documented versions that removed the code located between their installation markers and left only a line similar to:

<?php error_reporting(0); ?>

This can create confusion during cleanup.

Someone may open the file, see almost nothing dangerous and assume it was a false positive. In reality, the file may already have completed its purpose and copied the backdoors elsewhere.

This also means the original carrier can be useful for identifying the first infected site in a hosting account. Other sites may contain wp-vcd.php and modified theme files, while only the original installation contains the initial plugin or theme deployer.

What problems can WP-VCD create?

The visible symptoms are not identical on every infected site.

WP-VCD’s controllers could send additional code from remote infrastructure, allowing the behaviour to change without updating the original nulled plugin or theme. Historically documented monetization included black-hat SEO and malicious advertising. (Wordfence)

1. Popups and unwanted advertising

Visitors may experience:

Unexpected popups
New browser tabs
Full-page advertisements
Fake download offers
Browser-notification prompts
Adult, casino or scam advertisements
Advertisements that appear only occasionally

The administrator may not see the same behaviour during every test.

Conditional malware commonly limits how often it targets one visitor, or avoids displaying the payload to logged-in administrators. As a result, a site owner may check the homepage and conclude that nothing is wrong while actual visitors continue receiving unwanted content.

2. Redirects to suspicious websites

Remote payloads may redirect visitors away from the legitimate site.

The redirect may happen only:

On mobile devices
On the first visit
After arriving from a search engine
On selected posts
In specific countries
While logged out
Without an existing browser cookie

These conditions make the infection difficult to reproduce consistently.

The website can appear normal on the owner’s computer but redirect real customers to advertising, fake downloads, scams or other unwanted destinations.

3. Hidden backlinks and black-hat SEO

WP-VCD used infected sites to promote the websites distributing the nulled software.

The campaign could inject backlinks or other SEO-related code into compromised websites. This created a self-supporting distribution system:

Nulled-software sites distributed infected packages.
New victims installed those packages.
Compromised sites generated backlinks or traffic for the distributors.
The distributor websites gained greater search visibility.
More people discovered and downloaded the infected packages.

Wordfence found that the campaign could remotely deploy SEO-manipulation code to infected sites rather than storing all monetization behaviour inside the original deployer.

For the victim, this may result in:

Hidden links
Spam anchor text
Links appended to content
Off-screen HTML
Unrelated keywords in Google Search Console
Search impressions for suspicious terms
Reduced trust in legitimate pages

4. Remote PHP execution

The theme backdoor could receive new code from command-and-control servers and execute it on compromised websites.

This is more serious than one fixed redirect.

Once an attacker can deliver and execute new PHP, the visible behaviour can be changed at any time. One infected website may show popups, another may inject links, and another may appear quiet while retaining the same underlying access.

Wordfence documented fallback C2 addresses and a mechanism for changing the primary C2 domain, helping the campaign survive individual infrastructure disruptions. (Wordfence)

5. Cached payloads in `wp-tmp.php`

WP-VCD also used a fallback mechanism for remote payloads.

Code received from the C2 server could be saved locally as:

wp-tmp.php

If the remote servers later failed to respond, the malware could execute the most recently cached payload instead.

This means an unavailable C2 domain does not automatically make the site clean. Previously delivered code may still exist locally.

6. Rogue WordPress administrator accounts

Earlier WP-VCD variants were documented creating an administrator account with these details:

Username: 100010010
Email: te@ea.st

That account would appear in the normal WordPress database tables and could provide another way to access the dashboard.

A rogue administrator can be used to:

Upload another plugin
Edit theme files
Disable security tools
Add spam content
Create more accounts
Change settings
Re-establish access after file cleanup

The absence of this exact username does not prove the site is safe. It was associated with particular versions, and different or secondary payloads may create different accounts.

7. Repeated reinfection

One of the most frustrating symptoms is malware that appears to return after removal.

For example, an administrator deletes:

wp-vcd.php

or removes malicious code from one theme.

A few hours later, the file or code reappears.

This normally means another persistence point remains active:

A different infected theme
A modified wp-includes/post.php
The original deployer
A cached payload
Another compromised plugin
An infected staging site
Another WordPress installation in the same account

The malware is not returning from nowhere. A component that was not removed is rebuilding the deleted component.

8. Multiple infected themes

WP-VCD did not limit itself to the active theme. Historical deployers scanned installed themes and injected their functions.php files.

A website might therefore contain malicious code in:

/wp-content/themes/current-theme/functions.php
/wp-content/themes/old-theme/functions.php
/wp-content/themes/default-theme/functions.php
/wp-content/themes/unused-theme/functions.php

Cleaning only the active theme can leave several copies behind.

Unused themes should either be inspected and replaced or removed.

9. Cross-site infection inside one hosting account

WP-VCD’s lateral propagation is one of its most important behaviours.

Documented versions moved upward through the directory structure and then searched for additional WordPress installations in the same hosting environment. Detected sites could receive wp-vcd.php and the related core modification.

This matters when a hosting account contains:

/public_html/
/public_html/blog/
/public_html/shop/
/public_html/staging/
/public_html/old-site/
/public_html/client-site/

The forgotten staging site may be the infection source.

Cleaning the main domain while leaving another installation compromised can result in reinfection.

10. WordPress core modification

A modified core file can execute during normal page requests while the site continues to work.

This makes the infection less visible than a broken site.

The most notable historical indicators include:

/wp-includes/wp-vcd.php
/wp-includes/wp-tmp.php
/wp-includes/post.php

However, cleanup should not be limited to those exact files. Once unauthorized PHP has executed, other files may also have been added or altered.

11. Misleading file dates

The deployer could reset the modification timestamps of infected theme files after writing the backdoor.

Therefore, this approach is not reliable by itself:

“I sorted the files by modification date and found nothing recent.”

A file showing a date from several years ago may still have been modified later.

Use file dates together with:

Clean-package comparisons
Checksums
Code searches
File hashes
Access logs
Malware signatures
Unexpected ownership or permissions

12. Search-engine and reputation damage

Redirects, unwanted advertising and injected links can damage a domain’s search visibility and reputation.

Possible consequences include:

Irrelevant queries in Search Console
Ranking loss
Spam pages or links being indexed
Browser warnings
Antivirus detections
Hosting malware notices
Reduced visitor trust
Lower conversion rates

These effects may remain after the visible malware has been removed. Search engines and security vendors may need time to recrawl the website, and some warnings require a review request after the cleanup is completed.

13. Hosting suspension and resource usage

A hosting company may suspend an infected account after finding malicious PHP, spam redirects, repeated reinfection or unsafe activity.

Remote requests, repeated file writes and injected scripts may also contribute to:

Higher CPU usage
Increased PHP activity
Slow page generation
Additional bandwidth use
Intermittent timeouts
Large malware scan reports

A host may provide a list containing only the files its scanner recognized. That list should not be treated as a complete map of the compromise.

14. Possible exposure of stored secrets

Finding WP-VCD confirms that unauthorized PHP executed on the server.

It does not automatically prove that every password or API key was stolen. However, arbitrary PHP can read files and access information available to the hosting account.

Credentials should therefore be considered untrusted until rotated, including:

WordPress administrator passwords
Hosting credentials
FTP or SFTP accounts
Database credentials
SMTP passwords
API keys
WordPress authentication salts

Does WP-VCD store malware in the database?

WP-VCD is primarily a file-based infection , but database artifacts may also exist.

This distinction is important.

The main components generally appear as PHP files:

class.plugin-modules.php
class.theme-modules.php
wp-vcd.php
wp-tmp.php
modified theme functions.php files
modified WordPress core files

However, the database may contain secondary evidence.

Rogue users

Check:

wp_users
wp_usermeta

Look for unknown administrators, especially the historically documented 100010010 account.

Scheduled events

WordPress cron events are stored inside the cron option in:

wp_options

Not every WP-VCD infection creates a malicious cron event, but the schedule should still be reviewed for unknown hooks.

Suspicious options and widgets

Additional payloads may store scripts, links or settings in:

wp_options
widget_* options
theme_mods_* options

Injected posts or metadata

Search:

wp_posts
wp_postmeta

for unexpected scripts, hidden links, spam posts and unrelated content.

A clean database does not prove that WP-VCD has been removed. The primary persistence may remain entirely inside files.

Likewise, deleting one suspicious database user does not clean modified PHP files.

Can an inactive plugin still be dangerous?

An inactive plugin normally does not load through WordPress’s standard active-plugin system.

But an inactive nulled plugin can still be important in three ways.

It may have been active in the past

The deployer may already have copied the malware into themes and WordPress core files.

Deactivating the original plugin does not reverse those changes.

Another file may load it directly

A compromised theme, MU plugin or custom PHP file can load code without depending on WordPress’s active-plugin list.

It can identify the original entry point

An inactive nulled package containing class.plugin-modules.php may reveal how the server was first compromised.

Therefore, the correct conclusion is not:

“The plugin is inactive, so it cannot be responsible.”

The more accurate conclusion is:

“The plugin may no longer be the active persistence point, but it may have been the original carrier.”

How to detect WP-VCD

Take a full backup before deleting or editing anything.

Search for known filenames

With SSH:

find /path/to/public_html -type f \
\( -name "class.plugin-modules.php" \
-o -name "class.theme-modules.php" \
-o -name "wp-vcd.php" \
-o -name "wp-tmp.php" \)

Search for known code markers

grep -RInE \
'class\.(plugin|theme)-modules\.php|WP_V_CD|WP_CD_CODE|theme_temp_setup|wp_temp_setup|100010010' \
/path/to/public_html

Search for the loader

grep -RIn \
"dirname( __FILE__ ).*class.plugin-modules.php" \
/path/to/public_html

Also search for the theme equivalent:

grep -RIn \
"dirname( __FILE__ ).*class.theme-modules.php" \
/path/to/public_html

Verify WordPress core

wp core verify-checksums

WP-CLI compares installed WordPress core files against official WordPress.org checksums and reports files that do not match. It performs this check before fully loading WordPress. (WordPress Developer Resources)

To include unexpected files in the WordPress root:

wp core verify-checksums --include-root

Verify WordPress.org plugins

wp plugin verify-checksums --all

WP-CLI can compare plugins available through WordPress.org against their official checksums. (WordPress Developer Resources)

Premium, custom and privately distributed plugins may not have public checksums. Compare those manually against clean packages downloaded from their original vendors.

Review administrator users

wp user list --role=administrator

Check every account with the site owner.

Do not assume an account is legitimate because its username looks normal.

Review scheduled events

wp cron event list

Investigate unfamiliar hooks, especially those calling unknown files or functions.

Do not delete every cron event. WordPress and legitimate plugins depend on scheduled tasks.

Check the database

Replace wp_ with the site’s real table prefix.

SELECT
    ID,
    user_login,
    user_email,
    user_registered
FROM wp_users
ORDER BY user_registered DESC;

Check important options:

SELECT
    option_name,
    LEFT(option_value, 500) AS option_preview
FROM wp_options
WHERE option_name IN (
    'active_plugins',
    'recently_activated',
    'cron'
);

Search for readable indicators:

SELECT
    option_id,
    option_name,
    LEFT(option_value, 500) AS option_preview
FROM wp_options
WHERE option_value LIKE '%wp-vcd%'
   OR option_value LIKE '%wp-tmp%'
   OR option_value LIKE '%class.plugin-modules%'
   OR option_value LIKE '%class.theme-modules%'
   OR option_value LIKE '%100010010%';

No results do not guarantee a clean database. Payloads may be encoded, stored under unrelated names or absent from the database completely.

How to remove WP-VCD completely

Removing only the first loader line is not enough.

A full cleanup should cover the entire hosting account.

1. Preserve evidence

Before deleting the malware, save a quarantined copy outside the public web directory.

Record:

Suspicious filenames
File hashes
File sizes
Modification times
Plugin and theme names
Database findings
Unknown users
Scan reports
Relevant access-log entries

This can help identify the original carrier and explain later reinfection.

2. Remove all nulled software

Delete the entire infected plugin or theme directory.

Do not reinstall the same ZIP.

Replace required software with an official copy from:

The original developer
A reputable marketplace
The WordPress.org repository

3. Inspect every theme

Check the functions.php file of every installed theme.

Do not limit the investigation to the active theme.

Replace official themes with clean copies and remove unused themes that are not required.

4. Replace modified WordPress core files

Verify checksums and replace modified core files with clean files from the matching official WordPress release.

Pay particular attention to:

/wp-includes/post.php
/wp-includes/wp-vcd.php
/wp-includes/wp-tmp.php

Do not overwrite wp-content or wp-config.php without understanding what will be lost.

5. Compare all plugins with clean packages

For WordPress.org plugins, use checksum verification.

For premium plugins, compare the complete directory against a newly downloaded licensed copy.

Look for:

Additional PHP files
Modified plugin headers
Code before the normal opening comments
Unexpected remote URLs
File-writing functions
Unknown include statements
Third-party distributor branding

6. Inspect MU plugins and drop-ins

Check:

/wp-content/mu-plugins/
/wp-content/advanced-cache.php
/wp-content/db.php
/wp-content/object-cache.php
/wp-content/sunrise.php

These files can execute independently from the normal active-plugin list.

7. Review the database

Remove unauthorized administrator accounts.

Inspect cron, options, widgets, posts and post metadata.

Do not perform broad search-and-delete operations without reviewing the results. Legitimate page builders and plugins may contain scripts, encoded values and serialized data.

8. Scan every site under the account

Include:

Main websites
Addon domains
Subdomains
Staging sites
Development copies
Old installations
Forgotten backups containing executable PHP

One compromised installation can undermine the cleanup of the others.

9. Rotate credentials

Change:

Hosting password
WordPress administrator passwords
SFTP and FTP passwords
SSH credentials
Database password
Control-panel credentials
Connected email passwords where necessary

Regenerate WordPress authentication salts after the files are clean.

10. Update and harden WordPress

After cleaning:

Update WordPress
Update plugins and themes
Remove unused software
Disable dashboard file editing
Enable two-factor authentication
Review file permissions
Restrict administrator access
Add file-integrity monitoring
Review access logs
Keep off-site backups

11. Retest as an ordinary visitor

Test the website:

While logged out
In a private browser
From a mobile device
On another network
Through several landing pages
After arriving through a search result

Do not rely only on the administrator’s usual browser.

12. Request security and search reviews only after cleanup

After confirming the website is clean:

Request a new hosting scan
Review Google Search Console
Remove spam URLs where appropriate
Request blacklist reconsideration
Monitor indexed pages and search queries
Watch for file changes and reinfection

Common WP-VCD cleanup mistakes

Deleting only the nulled plugin

The plugin may have already copied backdoors elsewhere.

Removing only `wp-vcd.php`

An infected theme or neighbouring installation may recreate it.

Cleaning only the active theme

Inactive themes may contain the same backdoor.

Trusting old timestamps

WP-VCD could restore earlier modification times after changing files.

Ignoring the database

Rogue users or secondary artifacts may remain.

Checking only the database

The main persistence is usually file-based.

Scanning only the visible domain

Other WordPress installations under the account may be infected.

Reusing an old backup without scanning it

A backup created after the original infection may contain the same nulled package and backdoors.

Requesting blacklist removal too early

A failed review can delay recovery if persistence mechanisms are still present.

Indicators of compromise

Indicator	Location or type	Confidence
`class.plugin-modules.php`	Nulled plugin	High
`class.theme-modules.php`	Nulled theme	High
Loader referencing either modules file	Modified PHP file	High
`wp-includes/wp-vcd.php`	WordPress core area	High
Modified `wp-includes/post.php` loading `wp-vcd.php`	WordPress core	High
`WP_V_CD` or `WP_CD_CODE`	Code marker	High
Administrator `100010010`	Database	High when present
`wp-tmp.php`	Cached payload	Medium to high
`theme_temp_setup`	Function name	Medium
Unofficial distributor branding	Supply-chain evidence	Medium
Old timestamps on modified theme files	Forensic clue	Low by itself
Popups or conditional redirects	Symptom	Low by itself

The indicators should be considered together. A generic function such as include_once() or file_get_contents() is not malicious by itself.

A recent real-world discovery

In the case that led me to revisit WP-VCD, I found the loader inside an inactive nulled premium plugin.

The plugin name was not the important part. Other users may find the same loader inside completely different plugins or themes.

The important details were:

The package had been redistributed by an unofficial source.
Its legitimate PHP file had been modified.
It loaded class.plugin-modules.php.
The plugin was inactive but had probably been installed for years.
The rest of the hosting account still needed to be examined.

This case is a reminder that old malware can survive as forgotten code even when its original campaign is no longer receiving much attention.

A website does not become clean because the malicious plugin is inactive, the old C2 domain is unavailable or the site currently shows no redirect.

The real question is whether the deployer had already completed its work.

Frequently asked questions

What is `class.plugin-modules.php`?

It is a filename historically used as the primary deployer inside plugins modified by the WP-VCD campaign.

It is not a standard WordPress core file.

What is `class.theme-modules.php`?

It serves a similar purpose inside a modified or nulled theme.

Is the one-line loader the complete malware?

No. It checks for another file and executes it. The referenced file may then install backdoors in other locations.

Can WP-VCD infect an official plugin?

The campaign generally distributed modified copies of legitimate paid software through unofficial sites. The original plugin developer may have had no involvement.

Does an inactive plugin still run?

Normally it does not load through the standard WordPress active-plugin system. However, it may have executed earlier and created persistent files elsewhere.

Does WP-VCD infect the WordPress database?

Its main persistence is generally file-based. Some variants created a rogue administrator, and additional payloads may leave options, cron events or injected content in the database.

Why does WP-VCD come back after removal?

Another infected file, theme, site or cached payload is probably recreating the component that was deleted.

Can WP-VCD infect more than one website?

Documented versions searched for other WordPress installations in the same hosting environment and deployed additional malware to them.

Is deleting `wp-vcd.php` enough?

No. You must identify what created it and inspect themes, core files, plugins, database records and other installations.

Can a scanner remove WP-VCD completely?

A scanner can identify known signatures, but complete remediation also requires file-integrity verification, clean-package comparison, database review and an account-wide investigation.

Final conclusion

WP-VCD is an old WordPress malware family, but the lessons from it remain relevant.

The campaign succeeded because users installed compromised premium plugins and themes themselves. Once activated, the deployer could modify themes, add persistent core files, contact external servers and spread to additional WordPress installations.

The original nulled package may later be inactive, deleted or almost empty.

That does not mean the compromise is gone.

The most important principle is to distinguish between the carrier and the active persistence :

The nulled package brought the malware in.
The deployer spread it.
Other files may now be keeping it alive.

When class.plugin-modules.php, class.theme-modules.php or wp-vcd.php is found, treat the entire hosting environment as potentially compromised.

Preserve the evidence, replace unauthorized software, verify core files, inspect every theme, review the database, scan neighbouring installations and rotate credentials.

Anything less can leave the component that brings the malware back.

SiteGround Suspended a Client Site for Malware — Removing a Tiny File Manager Backdoor (single-compiler.php)

MD Pabel — Fri, 19 Jun 2026 00:23:37 +0000

Quick answer: SiteGround suspends a site and shows “Malware detected for your site(s)” when its scanner finds malicious PHP on your hosting. In this cleanup the culprit was single-compiler.php — a renamed copy of the open-source Tiny File Manager hidden inside the WooDmart theme, plus 13 camouflaged secondary backdoors. Removing every flagged file, replacing the theme and core from clean sources, then using SiteGround’s Request Scan lifted the suspension the same day.

The two messages that brought this client to me

Public site: “This site is currently unavailable. If you’re the owner of this website, please contact your hosting provider to get this resolved.”

SiteGround dashboard: “Malware detected for your site(s). Web access for the affected site(s) under your hosting plan has been temporarily suspended until the malware is removed.”

A client’s WooCommerce store went dark mid-week. Loading the domain returned a plain SiteGround holding page instead of the storefront, and the SiteGround Client Area showed a red malware notice. This is a walkthrough of exactly what SiteGround flagged, what the malware actually was, how I removed it, and how I got the suspension lifted — written from the real cleanup, not a generic checklist. The specific files differ from site to site; the SiteGround flow and the method below stay the same.

Symptom 1: “This site is currently unavailable”

The first thing the client saw was the front end replaced by SiteGround’s suspension page. Unlike a normal WordPress crash, there was no “critical error,” no white screen — just a hosting-level notice with a rain-cloud icon. That distinction matters: when the message reads “If you’re the owner of this website, please contact your hosting provider to get this resolved,” the problem isn’t in WordPress, it’s that SiteGround has quarantined the account at the server level. Nothing you change in wp-admin will bring it back, because wp-admin is offline too.

The public-facing SiteGround suspension page — the site is quarantined at the server level, not just broken in WordPress.

Symptom 2: “Malware detected for your site(s)” in the SiteGround dashboard

Logging into the SiteGround Client Area, the Important Notifications panel carried the suspension reason: “Malware detected for your site(s). Web access for the affected site(s) under your hosting plan has been temporarily suspended until the malware is removed.” Next to it sat a Review button.

SiteGround’s malware notification in the Client Area, with the Review button that opens the evidence.

Clicking Review opens a long advisory (sections like “Take actions to avoid future infection” and “Using Site Scanner service is highly recommended”), and at the bottom four buttons: Close , View Evidence , Request Cleanup , and More. View Evidence is the one that matters — it lists the exact files SiteGround’s scanner flagged.

The Review modal. “View Evidence” reveals the flagged file paths; “Request Cleanup” is SiteGround’s paid option.

The evidence: 14 suspicious files

SiteGround reported 14 suspicious files , each with a full server path and a detection timestamp. The list is the real value here — it tells you precisely where to dig instead of scanning blind.

SiteGround’s View Evidence panel: 14 suspicious files, each with a full path. Client paths are redacted.

The flagged paths followed an obvious pattern — file names that look like real WordPress, plugin, and theme files but don’t exist in any clean install:

Flagged file	Where it sat	What it impersonates
`single-compiler.php`	wp-content/themes/woodmart/	A WooDmart `single-*.php` template (the primary backdoor)
`single-portfolio-first.php`	wp-content/themes/woodmart/	WooDmart portfolio template
`embed-merge.php`	wp-includes/	WordPress embed code
`border-call.php`	wp-includes/block-supports/	Core block-supports `border.php`
`class-wp-html-processor-url.php`	wp-includes/html-api/	Core `class-wp-html-processor.php`
`options-permalink-method.php`	wp-admin/	Core `options-permalink.php`
`post-types-ajax-response.php`	wp-content/plugins/woodmart-core/	WooDmart Core internals
`revslider-beta.php`	wp-content/plugins/revslider/	Slider Revolution file
`updraftplus-json.php`	wp-content/plugins/updraftplus/	UpdraftPlus file
`wp-config-sample.php`	public_html/ (root)	Real WP file — flagged because it had been modified

Scattering shells across wp-includes, wp-admin, the theme, and three different plugins is deliberate. It’s a distributed backdoor : delete one and the attacker still has nine more doors. This is why a “found the bad file, deleted it” approach gets sites re-suspended within days.

What the malware actually was: a Tiny File Manager backdoor

The headline file, single-compiler.php, sat in the WooDmart theme folder at 181 KB with a modification date stomped to match the legitimate theme files around it (a 2020 timestamp), so it blended into a directory listing. WooDmart has no template called single-compiler.php — the name simply borrows the theme’s single-*.php convention to look native.

single-compiler.php in the WooDmart theme directory — 181 KB and a stomped timestamp matching the real templates.

Opening it revealed it was not WordPress code at all. It was a renamed copy of Tiny File Manager (the open-source “H3K / CCP Programmers” single-file PHP file manager), weaponized as a full webshell. Tiny File Manager is a legitimate admin tool, but dropped into a hacked site it gives an attacker a browser-based control panel to browse the entire document root, upload and edit any file, delete files, change permissions, build and extract archives, and pull remote payloads in via its “upload from URL” feature — all without ever touching wp-admin. The copy here shipped with a hardcoded admin account and a noindex, nofollow meta tag so search engines wouldn’t surface it.

The other 13 files were lighter secondary shells and loaders following the same camouflage logic. Based on the outdated WooDmart Core plugin present on the site (older versions carried a known PHP Object Injection flaw) and the timestamps, the most probable entry point was a vulnerable/outdated theme component or a reused admin credential — not a SiteGround server breach. I cover how persistent shells like this survive a “delete the file” cleanup in this backdoor breakdown.

How to confirm a Tiny File Manager backdoor on your own site

If SiteGround (or any host) flags files like these, these commands confirm the infection over SSH before you delete anything. Tiny File Manager carries unmistakable signatures:

# Hunt for Tiny File Manager signatures anywhere in the site
grep -rl "Tiny File Manager" wp-content/ wp-includes/ wp-admin/
grep -rl "CCP Programmers" .
grep -rln '\$auth_users' wp-content/ wp-includes/ wp-admin/
grep -rl "FM_SESSION_ID" .

# Core/plugin files that should not exist will fail checksum verification
wp core verify-checksums
wp plugin verify-checksums --all

# Oversized or odd PHP hiding in the theme (a 181 KB "template" is a red flag)
find wp-content/themes/ -name "*.php" -size +50k -exec ls -lh {} \;
find wp-content/themes/woodmart/ -name "single-*.php"

wp core verify-checksums is the fastest way to expose the camouflaged core files — embed-merge.php, border-call.php, class-wp-html-processor-url.php and options-permalink-method.php all show up as files that don’t belong in a clean WordPress install. For a fuller detection routine, see my guide on how to detect WordPress malware.

The cleanup, step by step

SiteGround keeps the site quarantined while you work, but it gives you tools to operate. Under the Review modal’s More button you’ll find Whitelist IP (so you can reach the site to clean it) and Request Scan (to re-check once you’re done).

The More menu: Whitelist IP to regain access during cleanup, and Request Scan to trigger a free rescan (up to three per day).

Whitelist my IP via More → Whitelist IP, so I could reach File Manager and the site while everyone else stayed blocked.
Take a forensic backup first. Before deleting anything I copied the flagged files off-server so I had a record of the attack and a safety net.
Removed all 14 flagged files , then hunted for siblings the scanner missed using the grep and checksum commands above. Host scanners rarely catch 100% — assume there are more.
Replaced the theme and core from clean sources. I deleted the WooDmart folder and reinstalled it from a fresh download, and reinstalled WordPress core, rather than trusting files that had been tampered with.
Checked the usual hiding spots — wp-config.php, .htaccess, mu-plugins, the uploads directory, and wp_users/wp_options for rogue admins or injected autoloaded rows.
Hit Request Scan. SiteGround re-scanned, returned clean, and the suspension lifted the same day. (Rescans are free, up to three per day.)

The broader version of this recovery — including what to do when the host won’t restore access and how to clean over FTP — is in my hosting account suspended malware recovery guide. I documented a similar host-level suspension on a different provider in this Bluehost recovery case study.

Why I re-scanned with Wordfence after SiteGround cleared it

A passing host scan is necessary, not sufficient. SiteGround’s scanner is signature-based and tuned to protect the server, not to give you a forensic all-clear — it sometimes misses lower-signal shells and injected database content. Once the site was back online I installed Wordfence and ran a full scan as an independent second opinion. It confirmed the file system was clean and surfaced nothing new, which is exactly the confirmation you want before you call a site recovered. Two different engines agreeing is far stronger than trusting one.

Hardening so the suspension doesn’t repeat

A clean site that keeps the same passwords and the same vulnerable plugins gets reinfected. After the rescan passed, I:

Rotated every password — WordPress admins, SiteGround account, FTP/SFTP, database, and email.
Regenerated the secret keys and salts in wp-config.php to force-log-out any session an attacker still held.
Updated WordPress core, the WooDmart theme, and all plugins to current versions, and removed anything nulled or unused.
Disabled in-dashboard file editing (define('DISALLOW_FILE_EDIT', true);), enabled two-factor on admin logins, and tightened file permissions.

My full post-cleanup routine is in what to do after fixing a hacked WordPress site.

Result

The suspension was lifted the same day the cleanup finished, the storefront came back online, SiteGround’s rescan returned clean, and a follow-up Wordfence scan confirmed no reinfection. Total downtime was a single working session rather than the days a back-and-forth with support typically costs.

“My website was suffering from some redirect malware. MD was able to take care of the problem for a reasonable fee. For me, he was a lifesaver. I will certainly go to him first should something like that happen again.” Kendall Miller, Founder

When to get help

If SiteGround has suspended your site and the evidence list looks anything like the one above — disguised PHP files scattered across core, theme, and plugins — the safe move is to remove every shell, not just the obvious one, before you request a rescan. I’ve cleaned 4,500+ hacked WordPress sites and lifted host suspensions on SiteGround, Bluehost, Hostinger, and more. If you’d rather not do it yourself, my WordPress malware removal service handles the whole thing — diagnosis, cleanup, rescan, and hardening — or you can hire me directly.

Frequently asked questions

Why did SiteGround suspend my site for malware?

SiteGround runs automatic malware scans on hosted accounts. When the scanner finds malicious PHP — a webshell, backdoor, or injected loader — it temporarily suspends web access to protect its servers and IP reputation. The site stays quarantined until you remove the flagged files and pass a rescan.

What does “Malware detected for your site(s)” mean in SiteGround?

It means SiteGround’s scanner found malicious code in your hosting account and has suspended web access until it’s cleaned. Open the Client Area, click Review on the notification, then View Evidence to see the exact file paths. Remove every listed file (and any siblings), then use Request Scan.

Is single-compiler.php a real WooDmart theme file?

No. WooDmart has no single-compiler.php template. The name copies the theme’s legitimate single-*.php naming so it blends in. In this case it was a renamed Tiny File Manager — an open-source file manager weaponized as a backdoor. If you find it in your theme folder, delete it and scan for more shells.

How do I get my SiteGround site unsuspended after malware?

Whitelist your IP (Review → More → Whitelist IP) to regain access, remove every file in the View Evidence list plus any hidden siblings, replace tampered core/theme/plugin files from clean copies, then click Request Scan. A clean rescan lifts the suspension, usually within minutes to a few hours.

Does SiteGround’s scanner catch all the malware?

Not always. Host scanners are signature-based and can miss lower-signal shells or database injections. After SiteGround clears your site, run an independent scan with Wordfence or a manual file review. Two engines agreeing — plus a checksum verification of core and plugins — is a far stronger all-clear than one passing scan.

Last updated: April 2026 by MD Pabel, WordPress Security Specialist — 4,500+ sites cleaned.

VirusTotal Flagged Your Website? What It Really Means — and How to Actually Get Removed

MD Pabel — Sat, 06 Jun 2026 04:04:08 +0000

Quick answer VirusTotal has no blacklist of its own and cannot add or remove your website. It is an aggregator that mirrors the verdicts of 70+ antivirus engines and URL/domain blocklisting services. To clear a flag you fix the underlying problem on your site, then ask each flagging vendor — not VirusTotal — to re-scan and clear you. A genuinely clean site that is flagged is usually a false positive; a flag that will not go away on a previously hacked WordPress site almost always means leftover malware.
You scanned your domain on VirusTotal, saw something like 3 of 94 security vendors flagged this URL as malicious, and your first instinct was to find the “remove from VirusTotal” button. There isn’t one — and that is not a bug. Understanding why is the difference between wasting a week emailing the wrong people and getting your site cleared in a day or two. I’m MD Pabel, and I’ve cleaned more than 4,500 hacked WordPress sites. A misread VirusTotal report is one of the most common screenshots clients send me, usually with the same question: “How do I get off VirusTotal’s blacklist?” The short version is that VirusTotal doesn’t have one. Here’s what the screen actually means and exactly what to do about it.

VirusTotal is not a blacklist. It’s a mirror.

VirusTotal is owned by Google and runs anything you submit — a file, URL, domain, or IP — through more than 70 antivirus engines and URL/domain blocklisting services at once. That’s its entire job: collect verdicts from many independent vendors and show them in one place. The part most people miss is that VirusTotal produces no verdict of its own. It doesn’t decide your site is malicious. It reports what Kaspersky, BitDefender, Sophos, Google Safe Browsing, and the rest are saying about you, and it aggregates those answers into a tidy count. So “VirusTotal blacklisted my site” is technically impossible. What actually happened is that one or more of the engines VirusTotal queries flagged your domain, and VirusTotal is simply displaying their results together. Think of VirusTotal as a scoreboard, not the referee. Shouting at the scoreboard won’t change the score. You have to go to the officials who put the numbers up there.

Why you can’t “remove” your site from VirusTotal

This trips up almost everyone, so it’s worth being blunt. Even in the rare case VirusTotal hid a flag on its own display, the people running the antivirus product that flagged you would still be blocked from your site. The warning lives in the vendor’s database, not in VirusTotal’s. Only the vendor that flagged you can clear it. A couple of other quirks matter:

Domain reports don’t even carry a verdict. A VirusTotal domain page mostly shows relationships and history, not a malicious/clean ruling. The actionable verdicts come from URL scans.
VirusTotal caches results. A site you fixed yesterday can keep showing an old verdict until the specific URL is re-scanned, which is why people panic when their “cleaned” site still looks flagged.
The takeaway: the fix never lives inside VirusTotal. It lives at the source (your website) and at each vendor that flagged you.

First, figure out which problem you actually have

Two completely different situations get lumped under “VirusTotal flagged my site,” and they have opposite fixes. Get this wrong and you’ll either waste weeks or, worse, send delisting requests for a site that is still infected.
A true false positive. Your site is genuinely clean and a vendor’s automated system flagged it by mistake. This is common with brand-new domains, aggressive heuristics, shared-hosting IP reputation, or a legitimate script that loads an unfamiliar external domain.

1. A real, lingering infection. Your site was hacked, you (or a plugin) “cleaned” it, but the flag persists because malware is still there or has already come back. For WordPress sites, the second case is far more common — and it’s the one generic “just report a false positive” articles get dangerously wrong. If your site was hacked, the flag usually isn’t a mistake. It’s the symptom. (If your malware seems to keep returning no matter what you do, read why WordPress malware keeps coming back.) Here’s how to tell which situation you’re in before you do anything else:

Signal	Likely a false positive	Likely still infected
Recent history	No hack, nothing changed	Site was hacked or you saw symptoms recently
What’s flagged	Your root domain, no specific bad URL	A specific path, file, or injected page
Which engines	1–2 obscure engines	Reputable engines (Google, major AVs), or the count is rising
The label	“Suspicious”	“Malware site,” “Phishing site,” “Malicious”
On your site	Nothing unusual in files or database	Unknown files, redirects, spam pages, or new admin users
After re-scan	Clears, or stays at the same low number	Comes back or increases

How to read your VirusTotal report

To contact the right people, you have to read the report correctly. Three things matter:

The detection count is not a severity score

A result of “2 / 94” doesn’t mean your site is 2% bad. A single reputable engine labelling you a malware site is far more serious than five obscure scanners flagging you. Likewise, “0 / 94” doesn’t guarantee you’re clean — it only means none of the engines on VirusTotal flagged you (more on that below). Treat the count as a starting point, not a grade.

The label tells you the type of problem

Each engine returns a category: clean, unrated (never reviewed you), suspicious, malicious, malware site, or phishing site. Write down which engine reported which label. A “phishing site” verdict points to fake login or payment pages; a “malware site” verdict points to injected scripts or drive-by code. The label is your first clue about where to look on your own site.

Ignore the Community score

The Community score is voted on by registered VirusTotal users and weighted by their reputation. It can be skewed by anyone with an account and is not a reliable signal. Don’t make decisions based on it. By the end of this step you should have a simple list: which vendors flagged you, and with what label. That list is your to-do list — each vendor has its own delisting process. For the full diagnosis-to-delisting workflow across every blocklist, see my website blacklist diagnosis and delisting playbook.

If your WordPress site is genuinely infected (the usual case)

Security engines flag behavior, not appearance. Your homepage can look perfect while an injected script, a mobile-only redirect, a hidden spam directory, or a backdoor sits in your files or database. That’s why “but my site looks fine” is never proof of anything. If you’re comfortable on the command line, here are a few quick checks to confirm an infection before you assume it’s a false positive. (The full walkthrough is in my guide on how to detect WordPress malware.)

# PHP files modified in the last 7 days (common after a fresh hack)
find /path/to/wordpress -name "*.php" -mtime -7 -ls

# PHP files inside uploads — there should be ZERO
find /path/to/wordpress/wp-content/uploads -name "*.php"

# Search the database for the most common injection patterns
wp db search 'eval(' --all-tables
wp db search 'base64_decode' --all-tables

Here’s the part that catches people out: a single leftover backdoor re-infects a site within hours, and the next vendor scan re-flags you — sometimes after you’ve already requested delisting, which makes you look like you’re crying wolf. I once watched a client fail a Google review three times until we traced the reinfection to a payload hidden in the database, not the files (that case study is here). The rule: if you are not confident your site is 100% clean, requesting delisting is premature. You will fail the review and burn time.

The real removal process, step by step

1. Clean the site completely. Every backdoor, injected file, malicious database row, rogue admin user, and poisoned .htaccess rule. Half-measures are why flags come back. (My expert malware-removal guide covers the process; the post-cleanup checklist covers what comes next.)
1. Verify with more than one scanner. Don’t trust a single tool. Cross-check with Sucuri SiteCheck, Quttera, and Google’s Safe Browsing status before you declare victory.
1. Re-scan the flagged URL on VirusTotal. This clears VirusTotal’s cached result so it reflects your cleaned site, not the snapshot from when you were hacked.
1. Contact each flagging vendor directly. Use an email address at your own domain (it helps prove ownership), include a link to the VirusTotal report, and attach proof of a clean scan. Submitting from a domain email with clean-scan evidence is the single biggest factor in getting a fast review.
1. Be patient with propagation. Some vendors clear you within hours; others take days, and full propagation across every cache can take up to about 30 days. Don’t re-submit hourly — that doesn’t speed anything up.
1. Handle the vendors VirusTotal doesn’t show. See the next section — this is the step people forget, and it’s why warnings persist in browsers even after VirusTotal reads 0 / 94.

The vendors VirusTotal won’t show you

VirusTotal covers a lot of ground, but not everything. Several of the warnings that actually scare your visitors away come from sources that may never appear in your VirusTotal report:

Google Safe Browsing powers the red “Dangerous site” interstitial in Chrome, Firefox, and Safari — the warning the largest share of your visitors will actually hit. Check your status separately and request a review in Google Search Console under Security Issues. If Google is the problem, see my Google blacklist removal service.
Norton Safe Web and similar reputation services often flag sites without showing up on VirusTotal. If Norton is warning on your domain, follow my Norton blacklist removal guide.
Avast and McAfee each maintain their own URL reputation systems with their own submission forms. See Avast blacklist removal and McAfee blacklist removal.
This is exactly why “0 detections on VirusTotal” doesn’t always mean every warning is gone. A clean VirusTotal report is encouraging, not final.

Want this handled instead?

I’ll be honest: cleaning a hacked WordPress site and then chasing down every vendor that flagged you is tedious, and it’s easy to get wrong. The usual failure points are a hidden backdoor that triggers reinfection, a delisting request sent too early, or a warning source (like Google or Norton) that nobody checked. I’ve handled all three across more than 4,500 cleanups.

If your site is flagged and you’d rather have a specialist clean it and clear every blocklist for you:

→ WordPress malware removal — full cleanup, root cause fixed → Blacklist removal — I file and follow up with every vendor → Hire me — done-for-you, with results reviewed before you pay

What clients say

“My website was suffering from some redirect malware. MD was able to take care of the problem for a reasonable fee. For me, he was a lifesaver. I will certainly go to him first should something like that happen again.”

— Kendall Miller, Founder

“I’m very satisfied with MD Pabel’s service. He saved my site from hackers and removed all malware attacks. Highly recommended.”

— Hassan Infinkey, eCommerce Owner

Frequently asked questions

Can VirusTotal blacklist my website?

No. VirusTotal maintains no blacklist and issues no verdicts of its own. It aggregates results from 70+ independent antivirus and URL-blocklisting engines. If you appear flagged on VirusTotal, it’s because one or more of those engines flagged you — and only that engine’s owner can remove the flag.

How do I remove my website from VirusTotal?

You can’t remove it from VirusTotal directly, because the flag lives with the vendor, not VirusTotal. Fix the underlying issue on your site, re-scan the URL to clear VirusTotal’s cache, then contact each flagging vendor from your domain email with proof of a clean scan and ask them to re-review.

Why is my site still flagged on VirusTotal after I cleaned it?

Three usual reasons: VirusTotal is showing a cached result (re-scan the URL), the flagging vendor hasn’t re-reviewed you yet, or — most often for WordPress — the site isn’t actually clean. A leftover backdoor reinfects within hours and gets you re-flagged. Verify the site is fully clean before assuming it’s a caching delay.

Does 1 of 94 detections on VirusTotal mean my site is infected?

Not on its own. A single obscure engine can be a false positive. But if that one detection comes from a reputable vendor and labels you “malware” or “phishing,” take it seriously and investigate. The detection count is a starting point, not a severity score — the engine and the label matter more than the number.

How long does it take to clear a VirusTotal flag?

It depends on the vendor. Some clear you within a few hours of a confirmed clean review; others take several days. Full propagation across every cache and product can take up to roughly 30 days. Submitting from your domain email with clean-scan evidence is the fastest path.

Last updated: June 6, 2026 by MD Pabel, WordPress Security Specialist — 4,500+ sites cleaned.

How to Secure WordPress Without Security Plugins

MD Pabel — Wed, 03 Jun 2026 03:04:23 +0000

Quick answer: Yes, you can secure WordPress without any security plugins. Most real protection comes from two layers you control directly: application hardening (wp-config.php rules, correct file permissions, disabled file editing) and server-level controls (a web-server firewall, blocked PHP execution, least-privilege database access). Plugins add convenience and monitoring, not the foundation.

After manually cleaning more than 4,500 hacked WordPress sites, one pattern repeats: the site that gets reinfected almost always had a security plugin installed, and was breached anyway. The plugin was never the problem. It just was not the foundation.

The numbers explain why. Patchstack’s 2026 report counted 11,334 new WordPress vulnerabilities in 2025, a 42% jump year over year. Plugins accounted for 91% of them; WordPress core had just two. The weighted median time from public disclosure to first exploitation was five hours. You cannot patch fast enough to win that race. The most reliable thing you can do is shrink what an attacker can reach in the first place, and almost all of that work needs zero plugins.

This guide is the no-plugin path: the server-level and application-level hardening I apply after every cleanup. If you would rather compare dedicated tools, see my breakdown of the best WordPress security plugins, but read this first, because no plugin replaces the basics below.

Server-level vs. application-level security: the model that matters

Every control on a WordPress site lives at one of two layers, and knowing which is which tells you what you can do without a plugin.

Application-level security runs inside WordPress: PHP, wp-config.php, the database WordPress reads, and the admin dashboard. Every security plugin lives here. So do wp-config rules and file-editing controls.

Server-level security runs below WordPress: the web server (Apache, Nginx, or LiteSpeed), the PHP runtime, the file system, the MySQL or MariaDB server, and the operating system. A request reaches this layer before WordPress ever loads.

The difference is when each layer acts. A server-level firewall can drop a malicious request before a single line of PHP runs, which is cheap and resilient. An application-level plugin only sees a request after WordPress has loaded, which is exactly why malware that gains file access can often switch the plugin off and hide its tracks.

Layer	Where it runs	Good at	Blind to	No-plugin tools
Application	Inside WordPress (PHP)	Login rules, 2FA, WordPress-specific hardening, change logging	Anything outside WordPress; can be disabled once files are compromised	wp-config.php constants, functions.php filters, WP-CLI
Server	Below WordPress (OS, web server, DB)	Dropping bad requests early, blocking PHP execution, file integrity, brute-force throttling	WordPress user authentication; intent of a “valid” request abusing a plugin	.htaccess / Nginx rules, php.ini, ModSecurity, fail2ban, file permissions

But neither layer wins alone. Patchstack tested standard hosting defenses in 2025 and found that 87.8% of real-world WordPress attacks bypassed them, because those attacks abuse WordPress against itself: a vulnerable plugin doing exactly what its own code permits. So the goal is not “server good, plugin bad.” It is: reduce the attack surface first, then harden both layers.

Why fewer plugins is itself a security control

Every plugin is third-party code running on your server with broad access to your files and database. With 91% of WordPress vulnerabilities living in plugins, and many of them in abandoned plugins that will never be patched, the math is simple: the less third-party code you run, the less an attacker can target and the less you have to patch inside that five-hour window.

In nearly every cleanup I do, the entry point is a vulnerable or nulled plugin or theme, not WordPress core. So treat plugin reduction as a control in its own right. If a feature can be achieved with a few lines in functions.php or a single server rule, prefer that over installing a plugin. Audit quarterly, and delete rather than just deactivate anything unused, because a deactivated plugin still sits on disk and remains reachable. For the broader maintenance routine, see my full guide on how to secure a WordPress site.

Application-level hardening (no plugins required)

These controls live in wp-config.php, your server config, and core WordPress settings. None of them need a plugin.

Lock down wp-config.php

This file holds your database credentials and secret keys, so it deserves the tightest permission on the site. Set it to 600 (or 640 if your host requires group read), and if your host allows it, move it one level above the web root.

# Restrict wp-config.php to the owner only
chmod 600 wp-config.php

Disable the built-in file editor

This is the single most useful one-line change I recommend after a cleanup. When an attacker gets one admin session, the first thing they often do is open Appearance › Theme File Editor and paste a backdoor straight into the theme, no FTP needed. I have traced more than one reinfection back to exactly this path, including a hidden backdoor in a client’s site. Turning the editor off removes that one-click route.

// In wp-config.php, above the "stop editing" line
define( 'DISALLOW_FILE_EDIT', true );

Disable file modifications (advanced)

DISALLOW_FILE_MODS goes further: it blocks plugin and theme installs, deletions, and updates from the dashboard. That is powerful, but it has a real trade-off, you also lose automatic updates. Only use it if you patch another way, such as WP-CLI or a deployment pipeline. On a site that is managed by hand and rarely changes, it is one of the strongest anti-tamper controls available.

// Blocks ALL file changes from the dashboard, including updates
define( 'DISALLOW_FILE_MODS', true );

Refresh secret keys and force HTTPS in the admin

Your authentication salts sign the cookies that keep you logged in. Regenerating them invalidates every existing session, which is exactly what you want after any suspected breach, it logs out an attacker who may be riding a stolen cookie. Grab a fresh set from the official generator and replace the matching block in wp-config.php.

# Generate a fresh set of keys and salts
https://api.wordpress.org/secret-key/1.1/salt/

// Then force the admin and login over HTTPS
define( 'FORCE_SSL_ADMIN', true );

Block PHP execution where it does not belong

Most webshells get dropped into wp-content/uploads, because that folder is writable. Blocking PHP from running there neutralizes the payload even if the file lands on disk, which is one of the highest-value server rules you can add. It is the same principle behind a lot of the .htaccess malware cleanups I handle.

# Apache: place in wp-content/uploads/.htaccess
<Files *.php>
  Require all denied
</Files>

# Nginx: add to your server block
location ~* /wp-content/uploads/.*\.php$ {
  deny all;
}

Shut down XML-RPC if you do not use it

xmlrpc.php is a common target for brute-force amplification and pingback abuse. If you do not use the WordPress mobile app, Jetpack, or an external publishing tool, block the endpoint at the server. Confirm those integrations are not in use first, since this will break them.

# Apache: in the root .htaccess
<Files xmlrpc.php>
  Require all denied
</Files>

Strip version giveaways and manage application passwords

Remove the WordPress generator tag, delete the default readme.html, and uninstall unused themes so attackers cannot fingerprint exact versions. Application passwords are another quiet risk: they grant API access and, if leaked, behave like a backdoor. If you do not connect external apps over the REST API, disable them with a one-line filter, no plugin and no Wordfence required.

// In functions.php or a small must-use plugin
add_filter( 'wp_is_application_passwords_available', '__return_false' );

For login-specific measures beyond this, such as 2FA and protecting the login URL, see my dedicated guide on how to secure WordPress login.

Server-level hardening (no plugins required)

What you can do here depends on your hosting. On shared hosting you usually have file and .htaccess access but no SSH or php.ini control, so ask your host what is already enabled. On managed WordPress hosting , much of this is configured for you. On a VPS , you control all of it. Apply what your environment allows.

Set correct file and folder permissions

The standard is 755 for directories, 644 for files, and 600 for wp-config.php. Never use 777 on anything; it lets any process write to that file, which is how a lot of cross-account infections spread on shared servers. If you do not have SSH, you can correct permissions with my no-SSH PHP permissions script.

# Run from your WordPress root over SSH
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

Disable directory browsing

If directory listing is on, anyone can browse your folder structure and read what plugins and backups you have. Turn it off at the server.

# Apache: in the root .htaccess
Options -Indexes

Restrict dangerous PHP functions

Most webshells rely on PHP’s command-execution functions. Disabling the ones a normal WordPress site never needs removes a huge amount of a shell’s capability even if one is uploaded. Test after applying, since a few hosts or plugins may need one of these.

# In php.ini (VPS / managed with access)
disable_functions = exec,shell_exec,system,passthru,popen,proc_open

Add a server firewall and brute-force blocking

This is the server-level equivalent of what a plugin firewall does, except it acts before PHP loads. On a VPS or capable managed host, run ModSecurity with the OWASP Core Rule Set to filter malicious requests, and fail2ban to ban IPs that hammer wp-login.php. On shared hosting, ask whether ModSecurity is already active; it often is.

Lock down the database

Give WordPress a dedicated MySQL user scoped to a single database, with a long random password. Do not use the root account, and never reuse the same database user across multiple sites, that is how one compromised site becomes several. Changing the wp_ table prefix is sometimes suggested too, but it is a low-impact, defense-in-depth measure that can break a site if done carelessly, so I treat it as optional rather than essential.

Enforce HTTPS and security headers at the server

Security headers are pure server config, no plugin needed. They harden the browser side against clickjacking, MIME sniffing, and protocol downgrade.

# Apache: in the root .htaccess
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

The one thing hardening cannot replace: knowing when something changed

Hardening shrinks the attack surface. What it does not do is tell you the day a brand-new vulnerability in a plugin you actually use gets weaponized within five hours. That detection-and-virtual-patching gap is the honest, legitimate argument for security plugins. Pretending hardening is invincible is how sites get reinfected after a cleanup.

You can cover the monitoring half without a plugin. WP-CLI verifies your core and plugin files against the official checksums, so any modified or injected file shows up immediately.

# Verify core and all plugin files against wordpress.org checksums
wp core verify-checksums
wp plugin verify-checksums --all

Schedule those commands with a cron job and you have genuine file-integrity monitoring with zero plugins. The one piece that hardening and checksums still cannot cover is virtual patching of an unpatched vulnerability inside that five-hour window. For that you genuinely need either a server WAF rule, a managed host that does it for you, or a focused security plugin. Be honest about that single trade-off instead of treating “no plugins” as a complete defense.

No-plugin WordPress hardening checklist

1. Delete unused plugins and themes; keep everything else updated.
1. Set permissions: 755 directories, 644 files, 600 for wp-config.php.
1. In wp-config: add DISALLOW_FILE_EDIT, refresh salts, force SSL in admin.
1. Block PHP execution inside wp-content/uploads.
1. Disable directory browsing.
1. Restrict dangerous PHP functions in php.ini.
1. Scope the database user to one database with a strong password.
1. Block xmlrpc.php if you do not use it.
1. Add HTTPS and security headers at the server.
1. Schedule WP-CLI checksum verification as integrity monitoring.

When to bring in a specialist

One critical caveat: if your site is already infected, do not harden on top of the infection. Locking down a compromised site just locks the attacker’s backdoor in with it. Clean first, then harden. In 4,500-plus cleanups I have seen well-meaning owners apply every step above while a webshell sat untouched in an uploads folder, which is how, for example, this Bluehost site recovery started.

If your site is currently hacked, redirecting to spam, or blacklisted, my WordPress malware removal service handles the cleanup manually, with no data loss, and applies the hardening in this guide afterward. Prefer to hand the whole thing off? You can hire me directly.

Frequently asked questions

Can you really secure WordPress without any plugins?

Yes. The core of WordPress security is reducing your attack surface and hardening configuration, and almost all of that happens in wp-config.php, your server settings, and file permissions, none of which need a plugin. The only gap is real-time virtual patching, where a server WAF or focused plugin still helps.

Should I remove my security plugin if my host already has server-level security?

Often yes, if your managed host runs a server WAF, malware scanning, and brute-force protection, a heavy all-in-one plugin is largely redundant and only adds load. But server-level tools cannot show WordPress login activity or enforce 2FA, so keep an application-level option for those specific needs.

What is the difference between server-level and application-level security?

Server-level security runs below WordPress (web server, PHP, database, OS) and acts on a request before WordPress loads. Application-level security runs inside WordPress as PHP and only sees a request after it loads. Server-level is harder to disable; application-level is better at WordPress-specific rules. Strong sites use both.

Does disabling file editing in wp-config actually stop hackers?

It closes one specific, very common path. Attackers who steal an admin session frequently use the built-in theme and plugin editor to paste a backdoor instantly. Setting DISALLOW_FILE_EDIT removes that one-click option, so they must find another route. It is not a complete defense, but it is a high-value one-line change.

Is changing the WordPress database prefix worth it for security?

Only marginally. Renaming the wp_ prefix can frustrate some automated attacks that assume default table names, but it does not stop a determined attacker and can break your site if done incorrectly. Treat it as optional defense-in-depth, well after permissions, file-edit lockdown, and PHP-execution blocking.

Last updated: June 3, 2026 by MD Pabel, WordPress Security Specialist, 4,500+ sites cleaned.

DEV Community: MD Pabel

WordPress Malware Removal Is Not Just “Delete the Bad File

Malware can exist across several WordPress layers

A clean scan is not proof that the site is clean

Reinfection does not always mean the attacker hacked the site again

One recent case used multiple persistence paths

My general WordPress malware cleanup workflow

1. Confirm the compromise

2. Determine the scope

3. Investigate persistence

4. Remove malicious components

5. Investigate the entry point

6. Recover reputation and search visibility

7. Monitor after cleanup

I turned this workflow into a book

Final thought

I’m Writing a Practical WordPress Malware Removal Book Based on Real Cleanup Cases

I’m Writing a Practical WordPress Malware Removal Book Based on Real Cleanup Cases

Why I’m Writing This Book

Start With the Symptom, Not the Word “Malware”

A Site Looking Normal Does Not Prove It Is Clean

What the Book Covers

This Is Not Meant to Be a Theory-Only Security Book

Early Access

wordpress #security #webdev #cybersecurity

WordPress Malware Removal for Developers & Site Owners — Built from Real Cleanup Cases

I’m Writing a Practical WordPress Malware Removal Book Based on Real Cleanup Cases

Why I’m Writing This Book

Start With the Symptom, Not the Word “Malware”

A Site Looking Normal Does Not Prove It Is Clean

What’s Inside the Book

This Is Not a Theory-Only Security Book

Early Access

Why I’m Writing a Practical WordPress Malware Removal Book

Why I Wanted to Write This Book

WordPress Malware Removal Is More Than Cleaning Files

Real Cases Instead of Generic Malware Examples

Conditional WordPress Redirect Malware

Malware Hidden in the WordPress Database

Hidden WordPress Administrators

Fake Plugins and Hidden Backdoors

Checkout Skimmers and Payment-Page Malware

SEO Spam and Hacked URLs

Server, DNS, and CDN Compromise

Malware That Keeps Coming Back

A Site Can Look Hacked Without Being Hacked

What the Book Covers

Who This Book Is For

The Book Is Still Under Development

📘 Read Chapter 1 Free

One Principle I Want the Book to Keep

How to Check Whether a WordPress Plugin or Theme Version Is Vulnerable

What the checker does

Try the checker

How to find your installed version

Plugin version

Theme version

WordPress core version

What an affected-version match means

A vulnerable version does not mean the website is hacked

What should you do after finding a match?

What does “no match found” mean?

Who can use this tool?

Check your WordPress software

How to Investigate WordPress ?p=, ?q=, and ?a= SEO Spam URLs

What is a query string?

Why ?p= can be legitimate

How ?p= was abused in the incident

?q= may also be legitimate

?a= and other single-letter parameters

Collect URLs before blocking them

Filter the domain with Python

Extract query parameters

Count the patterns

Review the server response

Check access logs

Build the narrowest possible rule

Handle a confirmed ?p= range separately

Test both malicious and legitimate cases

Why server-level handling matters

Why `?p=` can be legitimate

How `?p=` was abused in the incident

`?q=` may also be legitimate

`?a=` and other single-letter parameters

Handle a confirmed `?p=` range separately

Be extremely careful with WordPress `?p=` URLs

5. Cached payloads in `wp-tmp.php`