I’m having the same issues as the others. v0.6 was working fine for me, as was v0.5, but I just upgraded to v0.7 and now only the Database scan works.
Update: The File scan works now, but it takes forever to run, and displays virtually every single file I have, which is a lot since my blog is 4 years old and I post often.
Many of the ‘Descriptions’ are “File owned by apache user _removed_ and writable (-rw-r–r–)” which shouldn’t be an issue, and I just find it really difficult to use now… I’m looking forward to v0.8 that hopefully fixes this…
As it seems not all all (or in other words – most) web hosting providers seem to have some nasty settings that make all files writeable by the webserver. I will make the file permission check optional which should speed things up and should serve most needs.
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 65 bytes) in /var/www/web205/html/wp-content/plugins/exploit-scanner/exploit-scanner.php on line 261
What does this tell me and what ought I be doing?
I’m also having a problem running with version 0.7 sitting there spinning it’s wheels when “Files” is checked (WP 2.9 beta 2) on a 4 year old blog). I downgraded to version 0.6 just to check and 0.6 runs without a hitch and returns results within 10 seconds. Going back to 0.7 and it just sits there and spins it’s wheels again.No errors in error logs.
Sticking with version 0.6 for the time being. Sorry I couldn’t provide anymore info than that. Version 0.6 works, 0.7 does not.
I just pushed a new version that disables the Ajax functionality for now as it seems to be causing trouble in some constellations. Could those who saw spinning wheels with no results report back if the new version fixed the issue. Please be aware that running all the scans together can take quite a while depending on the amount of plugins/files and posts in your installation. If you run into trouble run the tests one by one.
Error message after update from within WP to v0.9 / WP 2.8.6 EN Checksums verified.
Warning: in_array() [function.in-array]: Wrong datatype for second argument in (...)/wp-content/plugins/exploit-scanner/exploit-scanner.php on line 341
I am no longer getting the spinning wheel at all. It runs for about a minute with an error showing up soon after starting, but after it finishes, I don’t see any other information. This is the final screen:
WordPress Exploit Scanner
Exploit scan
This script searches through your WordPress install for signs that may indicate that your website has been compromised by hackers. It does NOT remove anything, this is left for the user to do.
Scans to execute: General Infos File scan Database scan
Severities to show: Blocker Severe Warning Note
Skip check: File permission scan
Warning: in_array() [function.in-array]: Wrong datatype for second argument in /home/angelwood/www/wp/wp-content/plugins/exploit-scanner/exploit-scanner.php on line 1116
/>
PHP Memory Limit: MB (Max memory used by PHP.)
Upper File size Limit: KB (Skip files larger than this. Skipped files are listed at the end of scan.)
If you run into memory problems, increase the PHP memory limit or reduce the file size limit.
Custom search
You can also search the files and database on your site for a custom string:
That’s weird…
After about the 5th run through, that error went away and it is now finally working right!
I just gave 0.92 a try and the end result was the same as for 0.7. If I just check “General info” the plugin returns results within 6 seconds. If I check either Files or Database or both the plugin locks up my site both front end and admin with no results returned (same as with version 0.7).
No errors in any of my WP install error logs but I saw one on the main server log which showed up with version 0.7 as well. I wasn’t sure at the time if it applied to my site or not as it contains no identifying info. Still, it happened twice so…
[Mon Dec 14 13:20:39 2009] [warn] (103)Software caused connection abort: mod_fcgid: ap_pass_brigade failed in handle_request function
I then deleted 0.92 and reinstalled 0.6 for comparison and running the scan with 0.6 returned the expected results within 7 seconds with no errors or lockups.
Is there a difference in the functions and the way the scan is run in 0.6 as compared to version 0.7 and above besides being able to select the scan type? Is it correct to assume that version 0.6 runs all the scans seen in 0.7 and above? Does 0.6 not check the core files and DB as thoroughly?
Quick question: Why is there no change log to be found anywhere? Not even in the “readme.txt” file that comes with the plugin? Change logs help save asking a lot of questions that could otherwise be answered by reading the change log beforehand.
Just wondering. 🙂
BTW, I forgot to include some basic data in my last post:
PHP version: 5.2.11
MySQL version: 5.0.81-community-log
No permission restrictions and a well maintained install and DB.
End result in my case is that 0.6 runs fine and versions 0.7 and 0.92 do not. Any other test I can run, please don’t hesitate to let me know.
Just replying to say that I’m still having the same issue as Kirk described above, only I’m now using v0.93.
This is a great plugin, I just wish it worked as well as it did in v0.6…
Yup, I tried Version 0.93 too with the same results as with versions 0.7 though 0.92. Still no errors found. Kind of difficult to dig out a problem when there’s nothing in the error logs to go on. Maybe I need to have a talk with it? 😉
After testing all sorts of combinations of settings in WordPress Exploit Scanner 0.93 I finally got it to present the list of problems along with an error callout for the plugin itself. Up until now no combination of settings or having plugins activated or deactivated did anything but have the scan run approx. 9 minutes with a return to the default settings page, no list and a bit of text under the settings stating:
“Are you sure you want to do this?”
[link] “Try again”
Now, with all plugins deactivated except for Exploit Scanner and only “Filescan” under “Scans to execute” and “Severe” under “Severities to show” checked the scanner ran for approx. 2.5 minutes, returned a list of (supposed) severities plus an error callout under “Skip check”:
Warning: in_array() [function.in-array]: Wrong datatype for second argument in /home3/longmead/public_html/outofdate/wp-content/plugins/exploit-scanner/exploit-scanner.php on line 1116
/>
If I check “File Permissions Scan” then run the scan, the error isn’t returned.
Not the main problem I’ve been having (see my above comments) but I just thought you might want to know.
I’m beginning to believe the problem with version .7 and above is a conflict with one or more plugins but I haven’t had time to ferret which one(s) is the culprit. I don’t run any “exotic” plugins, just a few of the popular ones. I’ll do more testing as I get time.
Just an update to those who were experiencing the same issues as me, I just upgraded to v0.95 which appears to have fixed the timeout issues due to file scanning by scanning 50 (or x amount) of files at a time now, however it appears to always scan the files even if I deselect the files checkbox, and there is no confirmation that it scanned the database… also it always seems to scan by 50 even if change that number to 0…
…so an improvement, but there are still some bugs left.
This thing was nothing but a headache for me. I had to change the files from 50 to 40 to avoid memory problems. After spending several hours scanning 18,000 files, there was silence. Nothing say good or bad.
On top of that, it increased my database options table from 1 mb to 800 mb. Yes you read that right. 1 mb to 800 mb by adding records that don’t get deleted even when the plugin is deativated. I only noticed it when I tried to backup my database for upgrade to WP3.0. I had to use phpMyadmin to search for all the records and delete them and then repair the database to regain the empty space. It’s not something for the faint of heart.
If you’re going to try this, backup your database first and check the size afterwards.
I’ll second what Patyuen said – this causes huge bloat in the options table. Only run this in an emergency if you need to scan for exploits. Afterwards, you may need to manually delete these records.
