Large wfConfig Table Causing PHP Crash

  • Resolved Demonslay335

    (@demonslay335)


    7 years, 6 months ago

    Wordfence Security Version 7.1.15 [Free]
    WordPress 4.9.8 with all plugins updated
    CentOS 6 running WHM/cPanel

    We have an installation of WordFence that seems to be going crazy and overpopulating its config table. Eventually, it became several MB large, and caused PHP to crash due to the memory limit being surpassed.

    [26-Sep-2018 08:14:51 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 72 bytes) in /home/[redacted]/public_html/wp-content/plugins/wordfence/lib/wfConfig.php on line 280

    While the obvious answer to fix this crashing would be to up the memory limit, it would just mask the problem. I believe 256MB is plenty for most websites already (it’s fine for the other 20+ websites on this server).

    When inspecting the table wp_wfConfig, it seems to have a ton of duplicate entries. I had done a complete uninstall/re-install of the plugin in order to get the site back online, and a week later it is up to 14820 rows already (it added 10 more while typing this); I cannot remember how many it was before when it crashed the site, but it was in the hundreds of thousands possibly. I’ve checked with other sites I manage, and none have more than a few hundred rows.

    An example of the last 25 rows (unable to display the BLOB contents except individually thru PhpMyAdmin):

    
name val autoload
lastBruteForceDataSendTime [BLOB - 17 B] yes
lastBruteForceDataSendTime [BLOB - 17 B] yes
lastBruteForceDataSendTime [BLOB - 17 B] yes
lastBruteForceDataSendTime [BLOB - 17 B] yes
totalLoginHits [BLOB - 3 B] yes
totalLoginHits [BLOB - 3 B] yes
totalIPsBlocked [BLOB - 3 B] yes
total503s [BLOB - 3 B] yes
lastBruteForceDataSendTime [BLOB - 17 B] yes
lastBruteForceDataSendTime [BLOB - 17 B] yes
lastBruteForceDataSendTime [BLOB - 17 B] yes
totalLoginHits [BLOB - 3 B] yes
lastBruteForceDataSendTime [BLOB - 17 B] yes
totalLoginHits [BLOB - 3 B] yes
totalIPsBlocked [BLOB - 3 B] yes
total503s [BLOB - 3 B] yes
total503s [BLOB - 3 B] yes
lastBruteForceDataSendTime [BLOB - 17 B] yes
totalLoginHits [BLOB - 3 B] yes
totalIPsBlocked [BLOB - 3 B] yes
total503s [BLOB - 3 B] yes
total503s [BLOB - 3 B] yes
lastBruteForceDataSendTime [BLOB - 17 B]  yes
lastBruteForceDataSendTime [BLOB - 17 B] yes
lastBruteForceDataSendTime [BLOB - 17 B] yes

    Is this from the site being under attack? I haven’t received email alerts of crazy proportions, and all scans have been clean.

Viewing 4 replies - 1 through 4 (of 4 total)
  • wfasa

    (@wfasa)

    7 years, 5 months ago

    Hi @demonslay335,
    Sorry to hear you’re having this problem. Have you checked to make sure the database user your WordPress installation is running with has all permissions that are needed? You would be able to check this via Wordfence Tools > Diagnostics page.

    Thread Starter Demonslay335

    (@demonslay335)

    7 years, 5 months ago

    @wfasa

    Yep, no issues in the Diagnostics, everything has happy green checkmarks.

    Wordfence Config - Ability to save Wordfence settings to the database.
Checking basic config reading/writing - [✓] Basic config writing
Checking serialized config reading/writing - [✓] Serialized config writing

MySQL Database version and privileges.
Database Version - 5.5.61-cll
Checking if MySQL user has DELETE privilege - OK
Checking if MySQL user has INSERT privilege - OK
Checking if MySQL user has UPDATE privilege - OK
Checking if MySQL user has SELECT privilege - OK
Checking if MySQL user has CREATE TABLE privilege - OK
Checking if MySQL user has ALTER TABLE privilege - OK
Checking if MySQL user has DROP privilege - OK
Checking if MySQL user has TRUNCATE privilege - OK

    Here’s the diagnostics on the wp_wfConfig table.

    Name	Comment	Engine	Rows	Avg_row_length	Data_length	Index_length	Auto_increment	Create_time	Row_format	Collation	Version	Max_data_length	Data_free	Update_time	Check_time	Checksum	Create_options
wp_wfConfig		MyISAM	15999	81	3205484	1024		2018-09-26 21:53:52	Dynamic	utf8_general_ci	10	281474976710655	1894052	2018-10-08 14:35:38
    wfasa

    (@wfasa)

    7 years, 5 months ago

    Thanks for checking that. I’m not quite sure how this is possible, it’s not something I recall seeing before.

    The main issue obviously is that you somehow end up with duplicate rows. The rows in wfConfig are not created unless they don’t exist. For updates to options we use “ON DUPLICATE KEY UPDATE”. I’m wondering if there could be some problem with the indexes on the table but I’m not sure.

    Would it be possible for you to share a dump of the wfConfig table? If you can upload it somewhere safe, you could send a link for me to download it. If so, send the email to asa@wordfence.com.

    If you can send a Wordfence diagnostics report to asa@wordfence.com as well that would be helpful too. You can send it from the top of the Wordfence Tools > Diagnostics page.

    Thread Starter Demonslay335

    (@demonslay335)

    7 years, 5 months ago

    Ah, yes, that seems to be the issue.

    No index defined!

    I’ve compared with another WordPress site’s database and confirmed name should be the PRIMARY KEY. Not sure how the index was not added during install of the plugin, all other WordFence tables have their indexes.

    Thank you for the prompt response, this should fix the issue (I have to first consolidate the duplicate keys before MySQL will allow me to add the index). I’ll mark this as resolved and re-open it if I run into further issues.

    Thanks!

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘Large wfConfig Table Causing PHP Crash’ is closed to new replies.