Malware doesn’t start with a defaced homepage. It starts with small changes to performance. The site feels slower. Requests take longer. CPU usage creeps up.
And, because the browser doesn’t show you the source, you only notice it when your performance monitoring graphs look wrong.
So the fastest way to spot malware in WordPress is to treat performance as a signal. Malware creates patterns that normal requests never produce. When you know those patterns, you catch infections early.
Start with PHP execution spikes that don’t match your traffic
Open your host’s metrics and look for sudden increases in PHP runtime. Malware often hooks into early WordPress actions, so it runs before caching or template loading.
When a malicious loader executes on every request, you’ll see response times rise without a code deploy or traffic change.
Now run:
wp profile stage --all
This shows which stages of the WordPress bootstrap slow down.
If mu-plugins or plugins suddenly take far longer than usual, something injected code into those layers. When malware runs during the plugins stage, you’ll often see an extra 100–300 ms added everywhere.
If the core stage slows down, the infection sits in a modified core file.
You confirm that by running:
wp core verify-checksums
If WordPress reports modified files, you know exactly where to look next.
Use TTFB differences to locate where the payload hides
Open Chrome DevTools. Reload the page. Note the Time To First Byte.
Now log in and load the same page again.
If logged-out pages are slow and logged-in pages are normal, the payload lives in the theme. Malware often hides in:
header.phpfooter.phptemplate-parts/
Switch the theme temporarily. If the TTFB drops, the infection is in the template layer.
If both logged-in and logged-out pages are slow, the infection loads before the template renderer. This means you should inspect:
wp-config.php/wp-content/mu-plugins/- Autoloaded options
- Cron tasks
These locations execute regardless of theme, and malware knows that.
Look for unexpected outbound requests the browser never shows
Turn on the Network panel and reload.
Most malware doesn’t load through <script> tags, so you won’t see it directly in the browser. But you will see hints if your PHP logs show timeouts when trying to reach unknown domains.
Run this:
wp doctor check core
WP Doctor flags suspicious configuration issues, including writable directories and unexpected PHP settings.
Then run:
wp doctor check status
This reveals problems like large autoloaded options, which malware uses to store encoded payloads.
Now check your server logs for outbound connections.
You’ll often find patterns like:
- Calls to random .top, .info, or .ru domains
- Repeated failed remote requests
- Long-running
wp_remote_get()calls
These calls slow pages down because WordPress waits for a response before rendering anything else.
Use WP Profile to catch slow, injected functions
Next, run a full function-level audit:
wp profile eval-file --spotlight=0.01 wp-load.php
This command highlights functions taking longer than expected.
If you see suspicious functions like base64_decode, eval, str_rot13, or heavily nested anonymous functions, malware has hooked into early execution.
Legitimate code almost never uses these functions in a performance-critical path.
You can also run:
wp profile hook --format=table
This shows which hooks run slow. Malware often attaches itself to init, plugins_loaded, or wp_loaded. If these hooks take far longer than normal, you know something executed before WordPress even built the page.
Inspect cron for tasks that run too often
Malware loves WordPress cron. It uses it to fetch updates, send spam, or brute-force internal systems.
Run:
wp cron event list
Look for events firing every minute.
Look for events with generic names like update_data, reset_action, or mail_sender.
To test one event manually, use:
wp cron event run <event-name>
If the event hangs or triggers new outbound requests, you found the infection path.
Cron-based malware always shows up in performance graphs as recurring CPU spikes at perfect intervals.
This is one of the easiest early warnings because normal WordPress workloads don’t behave this consistently.
Compare admin and front-end performance to narrow the location
Load /wp-admin/.
If the admin is fast and the front end is slow, this is almost always theme-level malware.
If both are slow, the infection sits deeper.
WP Doctor helps confirm this. Run:
wp doctor check directories
If the uploads folder allows PHP execution, malware may be hiding inside a file with a harmless name like style.php , font-cache.php, or even just simple index.php files inside a year/month folder.
Removing the file usually drops the TTFB back to normal instantly.
Use file integrity to spot handwritten injections
Modified core files are a major red flag.
Run:
wp core verify-checksums
Any file that fails the check must be inspected.
When you open the altered file, look for:
- base64-encoded strings
- Random variable names
- Code injected after the closing PHP tag
eval()orassert()calls
Malware tries to run before caching, so core file manipulation always impacts performance.
A concise checklist to run on every suspicious slowdown
- Run wp profile to identify slow hooks and injected functions.
- Run wp doctor to find writable folders, large autoloaded options, and abnormal configuration.
- Compare logged-in and logged-out TTFB to locate the infection layer.
- Verify core files to detect modified bootstrapping.
- Inspect cron for tasks running too frequently.
- Check for outbound requests to unknown domains.
Clean the payload and retest
Remove the malicious file, cron job, or injected code.
Reload the page with DevTools open. You’ll often see the waterfall shrink immediately. Metrics stabilize. Cron spikes disappear. TTFB returns to normal.
Performance doesn’t lie. When malware runs silently in the background, it reshapes every graph and every request. Once you learn the patterns, you catch infections long before the site breaks.
Leave a Reply