donges
Forum Replies Created
-
I can say that whatever the devs did seems to have resolved the issue here. I rebuilt the wordfence environment and ran a new scan. Then ran a clamscan on the wfConfig.MYD table and it found no issues.
Which means that maldetect won’t move that table to quarantine.
Thanks for resolving!I can confirm this now.
After uninstalling again and dropping the wf tables, I reinstalled and reactivated. Nothing found with clamscan.Did an initial Wordfence scan of the site and immediately thereafter, the php.cmdshell malware was detected by clamscan.
So, while I don’t know what is being written to the wp_wfConfig table, there is the culprit. Then maldetect comes along and moves the file which breaks Wordfence.
What is happening on my end with this is that maldetect finds (or think it finds) {HEX}php.cmdshell.dC3.228.UNOFFICIAL malware in wfConfig.MYD and moves it to quarantine. Which is why it went missing.
I just ran across this today.
Uninstalled Wordfence, dropped the tables, reinstalled and reconfigured. All was well and clamscan did not find any trace of that malware.
Fast forward a couple hours and clamscan once again finds {HEX}php.cmdshell.dC3.228.UNOFFICIAL in that same table.
I am almost sure it is a false positive but can’t figure out what is loading the detected data in that table. Could it be when Wordfence kicks off a scan?