The Anatomy of a WordPress Malware Infection (And How Hosts Block It)

A WordPress malware infection almost never starts with the ugly part you eventually notice. By the time a site is redirecting visitors to a pill store or getting flagged by Google, the attacker has usually been inside for days or weeks. Understanding the sequence, from entry point to payload, is what lets you tell the difference between a real fix and a cosmetic one.

This post walks through the stages of a typical infection in the order they happen, then maps each stage to the server-level defense that stops it. We look at thousands of sites every month, and the pattern repeats with unsettling consistency.

What a WordPress Malware Infection Actually Is

Malware on WordPress is rarely a virus in the classic sense. It is almost always PHP code written to your filesystem or rows injected into your database, executed by your own server whenever a page loads. The attacker borrows your hosting resources, your domain reputation and your visitors.

That distinction matters because it explains why antivirus on your laptop does nothing, and why deleting one suspicious file rarely finishes the job.

Stage 1: The Entry Point

Every infection begins with a way in, and the way in is boringly predictable. Across the industry, known vulnerabilities in third-party plugins and themes account for the large majority of successful compromises, well ahead of core WordPress itself.

• Outdated plugins and themes with public exploit code, often patched weeks before the site was hit.
• Nulled or pirated premium plugins that ship with a backdoor already inside.
• Credential attacks: brute force on wp-login.php, XML-RPC amplification, or passwords reused from an unrelated breach.
• Server-neighbor contamination on cheap shared plans where accounts are not properly isolated.
• Stolen FTP or SFTP credentials lifted from an infected computer belonging to a developer or client.

Bots scan for these openings constantly. A brand new domain with no traffic will still see login probes within hours of its DNS going live.

Stage 2: The First File Write

Once the attacker has a foothold, the goal is not to cause damage yet. It is to write a small file somewhere unremarkable, usually a few hundred bytes of obfuscated PHP that accepts remote commands.

Common drop locations include wp-content/uploads, subfolders of a legitimate plugin, or the theme’s functions.php. Names mimic real WordPress files: wp-cache-config.php, class-wp-admin.php, index2.php. Automated scanners that only check core file hashes will walk right past them.

Stage 3: Persistence, Or Why One Backdoor Is Never One Backdoor

This is the stage most cleanups miss. A competent attacker plants redundancy, so that removing the visible malware still leaves a way back in.

• Multiple shells scattered across unrelated directories, sometimes ten or more.
• A rogue administrator account, often with a plausible name and a real-looking email.
• Malicious WP-Cron entries that re-download the payload on a schedule.
• Database-level injections in wp_options, where an autoloaded option quietly re-writes files on every request.
• A modified .htaccess or mu-plugins file that loads code no plugin list will ever show you.

Reinfection within 48 hours of a “successful” cleanup is almost always a persistence mechanism that was never found.

For a closer look at this topic, see our guide: Why XML-RPC Should Be Disabled on Your WordPress Host.

Related reading: Is Your WordPress Host GDPR and CCPA Compliant?.

Stage 4: The Payload

Only now does the site start behaving strangely. The payload depends on what the attacker monetizes, and the same backdoor can be resold to several operators.

• SEO spam and pharma hacks: thousands of hidden pages injected for keywords you would rather not rank for.
• Malicious redirects that fire only for visitors arriving from search, and only once per IP.
• Card skimmers on checkout pages, a serious risk for anyone running a WooCommerce store.
• Phishing kits hosted in a deep subfolder, impersonating a bank or a webmail login.
• Cryptominers and spam relays that quietly burn your CPU allocation and get your IP blacklisted.

Stage 5: Evasion

Modern WordPress malware is written to survive inspection. Code is base64 encoded, gzipped and split across files, so nothing greps cleanly. Timestamps get forged to match neighboring files.

Cloaking logic checks the user agent and serves clean HTML to logged-in administrators while showing spam to Googlebot and mobile visitors. That’s why an owner can swear the site looks fine while Search Console reports hundreds of injected URLs.

Where a Good Host Breaks the Chain

Here is the part the cleanup guides skip. Removal is a response; hosting architecture is what decides whether you ever need one. Each stage above has a matching server-level control.

Against the entry point

A managed web application firewall filters exploit attempts before PHP runs, and virtual patching covers a vulnerable plugin during the gap between disclosure and update. Rate limiting on login endpoints kills brute force traffic, and account isolation stops one compromised site from reaching another. Our approach to WordPress hosting security puts these at the platform layer rather than leaving them to plugins.

Against the first file write

Disabling PHP execution inside the uploads directory removes the most popular drop zone outright. Correct file permissions (typically 644 for files, 755 for directories) and a disabled theme editor cut off the easy paths. Keeping your stack on a supported PHP version matters too, since abandoned branches stop receiving security fixes.

Against persistence

File integrity monitoring flags any new or modified PHP file within minutes, including the ones named to look official. Real-time scanning that inspects the database, not just the filesystem, catches autoloaded option injections. Immutable daily backups with a retention window of 14 to 30 days give you a known-clean restore point from before the intrusion.

Against the payload

Outbound connection filtering blocks a skimmer from posting stolen card data. Resource limits contain cryptominers, and a CDN plus server-level DDoS protection absorbs the traffic spikes that often follow a compromise. Sites with recurring revenue, like membership platforms and online course sites, feel payload damage hardest because a single redirect breaks logins and refunds follow.

How to Check a WordPress Site for Malware Yourself

You do not need a forensics lab to get a useful read on whether something is wrong. Work through these in order:

1. Open Google Search Console and check Security Issues plus the Pages report for indexed URLs you never created.
2. Run the site through a public scanner such as Sucuri SiteCheck or Google Safe Browsing to see what an outside crawler sees.
3. List every user with the administrator role and remove any you cannot account for.
4. Sort files by modification date over SFTP and read anything PHP that changed recently.
5. Compare core files against a fresh WordPress download, and search the database for suspicious script tags.

The official WordPress hardening documentation covers the manual side well, and the OWASP Top Ten explains the underlying vulnerability classes if you want the deeper background.

Frequently Asked Questions

How can I remove malware from my WordPress site?

Effective WordPress malware removal takes four steps: isolate the site, restore from a backup taken before the infection date, reinstall core plus every plugin and theme from clean sources, then rotate all credentials (hosting, SFTP, database, and admin users). If no clean backup exists, a manual clean typically runs 2 to 6 hours for a single site because every backdoor has to be found individually.

How to tell if WordPress has been hacked?

The four most reliable signals are unexplained admin users, new or modified PHP files with recent timestamps, redirects that only trigger for search or mobile visitors, and a browser or Search Console warning. Sudden CPU spikes and outbound spam complaints are strong secondary indicators.

How to check a WordPress site for malware?

Use two layers: an external scanner like Sucuri SiteCheck for what visitors and crawlers see, plus a server-side scan that reads files and database rows. External-only tools miss backdoors entirely, since a dormant shell produces no visible symptom until it is called.

Why are people moving away from WordPress?

Most who leave cite plugin sprawl and maintenance overhead rather than WordPress itself, which still powers roughly 43 percent of the web. Managed platforms and serverless architectures reduce that burden without abandoning the CMS, which is why most sites stay put.

Want Malware Handled Before It Reaches Your Site?

We build the firewall, integrity monitoring, isolation and daily backups into every plan, so a plugin vulnerability does not become a weekend of cleanup. Talk to our team about migrating your WordPress site, and we will audit it for existing infections during the move.