Skip to content
Register

Help: Wordfence eating all my CPU allowance

Web Hosting by olespete 23 replies 3.6K views
steveipw

Member

7 #11
engzur said:
Enable Origin CPU monitoring

Cloudflare doesn't expose origin CPU. They expose origin response time, which correlates poorly under IO wait. I've graphed both.

Back to practical: olespete, Wordfence has a 

WFWAF_ENABLED
constant. Set it false in 
wp-config.php
, see if CPU drops. WAF rules compile to PHP opcode on every request if the cache directory isn't writable. Hostinger's 
open_basedir
restrictions break this silently.

I found this on a Denver client's site last month. Same symptoms, 90%+ CPU, "nothing changed."

zfs send | zfs receive. repeat.
KE

Member

#12

This. WAF opcode cache failing is classic shared hosting breakage. Hostinger moved some Paris nodes to new paths in June, 

/var/cache
no longer in 
open_basedir
for migrated accounts.

Following.

lucgone

Member

Le Baguette

#13
steveipw said:
WFWAF_ENABLED

Confirmed. The Lyon client had 

open_basedir
including 
/tmp
but Wordfence was trying 
/var/lib/php/sessions
for its compiled rules. PHP 8.1 on that node. Session path outside allowed paths, every request regenerates the WAF bytecode.

Olespete check your PHP version in Hostinger panel. If they bumped you to 8.1 or 8.2 recently, that's your culprit.

Vive la résistance... électrique
olespete

Member OP

Trust No One

#14

PHP 8.2.8. Updated July 15 according to the changelog they emailed. That fits.

Disabled WAF via constant, CPU dropped to 34% immediately. Still high but livable.

Not a supply chain attack. Just Hostinger breaking paths on a forced update. I feel stupid now but also angry.

airgapped, encrypted, faraday'd, still worried
MeritBudi

Member

7 #15

Same thing on my Hostinger Jakarta node. PHP 8.2 migration last week, Wordfence CPU from 15% to 89%. Found this thread via search, disabled WAF, back to normal.

They really should have emailed about path changes. I pay $11/month for this plan, not the cheapest.

RAJ

Member

7 #16
MeritBudi said:
Jakarta node

Mumbai too. Just checked two client sites, both spiking since July 20. Third site on older PHP 7.4, no problem.

This is a Hostinger-wide PHP 8.2 migration issue, not Wordfence specifically. Any plugin compiling to cache outside new 

open_basedir
would break.

Still switching one client to InterServer. Price lock is price lock.

your margin is my opportunity
walt22

Member

Austin

6 #17

I ran an ISP, not a web host, but same lesson: never migrate PHP versions without checking every customer's 

open_basedir
against their installed plugins' cache paths. Hostinger's automation clearly didn't.

Walt22, retired and opinionated.

hankels

Member

52 VPS and counting

3 #18
engzur said:
I said get a /24, you said "52 VPS" like that's an achievement.

I never said they were good VPS. Most are $2/year annual specials I use for monitoring nodes. The four Phoenix ones are proper.

But yes, I was guessing from outside. That's the point of cheap nodes.

seedbox, NAS, tape, and three offsite
NUT

Member

Bangkok

#19

Bangkok here. Four servers, all cheap, all self-managed. No Wordfence, I use CrowdSec on the nginx layer plus fail2ban. Shared hosting CPU mysteries are why I left shared hosting in 2019.

For those stuck: Wordfence has a 

wfConfig
key 
wafStatus
. Set to 
disabled
via database if you can't edit 
wp-config.php
. Same effect.

HO

Member

#20

Following this thread. Has anyone opened a Hostinger ticket about the PHP 8.2 path migration? What did they say?

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft