Sign up for a 30 Days FREE TRIAL

Contact Info

106 Anne rd Knoxfield 3180 Vic Australia

+61 (03) 82023009

info@ninjaweb.com.au

Contact us
Recommended Services
Supported Scripts
WordPress
Joomla
Drupal
Magento
Javascript
Angular
React
NodeJS
highCPU

How We Diagnosed and Stopped a WordPress CPU Flood on LiteSpeed

Everyone talks about DDoS attacks.

Most of the time, that’s not what’s actually happening.

What we dealt with here was something far more common and far more dangerous if misconfigured: distributed vulnerability scanning triggering PHP execution on every request.

This post breaks down exactly what happened, how we diagnosed it, and the precise fixes applied to bring a client server back under control.

No theory. Just execution.


The Problem: High CPU, Low Traffic

  • Dozens of lsphp processes
  • Each consuming 50–70% CPU
  • Load averages spiking above 15
  • No obvious single attacking IP

At first glance, it looks like a DDoS.

It isn’t.


Step 1: Identify the Pattern (Not the Noise)

Check active connections:

netstat -ntu | grep ':80\|:443' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20

Result:

  • Many IPs
  • Very few connections per IP

This tells you:

  • Not a single attacker
  • Not brute force
  • Distributed low-frequency bot traffic

Total connections:

netstat -ntu | grep ':80\|:443' | wc -l

Unique IPs:

netstat -ntu | grep ':80\|:443' | awk '{print $5}' | cut -d: -f1 | sort | uniq | wc -l

Conclusion: wide scan, not a flood.


Step 2: Identify What Is Being Requested

tail -n 300 /usr/local/apache/domlogs/example.com | awk '{print $7}' | sort | uniq -c | sort -nr | head -20

What we found:

/ws82.php
/shell.php
/vx.php
/access.php
/tool.php

These are not real files.

These are known malware/backdoor probes.

Bots are effectively asking:

“Are you already compromised?”


Step 3: Verify Server Integrity

find /home/user/public_html -type f -name "*.php" | grep -E "ws|shell|vx|access|tool|radio"

Result:

  • Only legitimate WordPress/plugin files
  • No malicious files

Direct test:

curl -I https://example.com/ws82.php
HTTP/2 404

Conclusion: server is clean.


Step 4: The Real Problem

Even though files didn’t exist, requests were still being processed like this:

Request → WordPress → index.php → PHP → CPU spike

WordPress fallback routing was handling non-existent PHP files.

That is what caused the load.


Step 5: Stop PHP Execution at the Edge

Add this to .htaccess:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} \.php$ [NC]
RewriteRule .* - [R=404,L]

Now the flow becomes:

Bot → LiteSpeed → 404 → done

No PHP execution.


Step 6: Block Known Exploit Patterns

RewriteRule ^(ws[0-9]+|shell|vx|access|tool|radio|press|new|ms|t|s|sid3|wp-good|wp-png|wp-blogs|wp-links-opml)\.php$ - [F,L,NC]

Now these requests return 403 instantly.


Step 7: Kill Active Load

pkill -u username lsphp

This resets PHP workers.


Step 8: Verify the Fix

curl -I https://example.com/ws82.php
HTTP/2 403

No WordPress. No PHP.


Step 9: Monitor Live System

top

Before:

  • 10–20 lsphp processes
  • Load above 15

After:

  • 2–3 lsphp processes
  • Load around 2–3
  • CPU mostly idle

Step 10: Supporting Hardening

Disable XML-RPC:

RewriteRule ^xmlrpc\.php$ - [F,L]

Block PHP in uploads:

RewriteRule ^wp-content/uploads/.*\.php$ - [F,L,NC]

Enable WAF protection (Wordfence or equivalent).


What This Was (and What It Was Not)

This was NOT:

  • DDoS
  • Brute force
  • Server compromise

This WAS:

  • Distributed vulnerability scanning
  • Automated probing for backdoors
  • WordPress fallback misuse

Why This Matters

Most WordPress setups:

  • Route all requests through index.php
  • Handle 404s dynamically
  • Execute PHP unnecessarily

This works under normal conditions.

It fails under automated scanning.


Final Result

  • CPU load dropped immediately
  • Server stabilized
  • Attack traffic became irrelevant

The bots never stopped.

They just stopped costing CPU.


The Real Lesson

You don’t stop traffic.

You control how your server handles it.

If a request doesn’t need PHP, it should never reach PHP.


Need Help Fixing High CPU on Your Server?

If your WordPress site is slow, unstable, or constantly under load, the issue is rarely just traffic. It is usually how the server handles requests and executes PHP.

We work directly on performance, security, and infrastructure – identifying the exact cause and fixing it at the root.

Explore related services:

Contact us to get your system under control

NinjaWeb – Your Digital Dojo

Share this Post