Eli

First of all, there is something very wrong if the scan is taking that long. In general, the Complete Scan should not take more than 1 hour even on a large site. If you have lots of plugins or if there are many other websites installed in sub-directories under the web-root of this main website then it can sometimes take longer, but it is usually an indication of a massive amount of scan errors or else something critically wrong with the website that is causing the scan to fail or slow to intolerable levels. Under normal conditions the scan should process each folder in under a second, only taking a few seconds if there is a problem with one or some of the files in that folder, but the scan is not designed to allow any folder to take more than 65 seconds without skipping that folder with an error or failing. So I don’t see any way that you could be observing each folder taking a whole hour.

You do have to lease the page open while the scan is running or it will not progress any further and the scan will need to be restarted. At this point it sounds like the scan would need to be restarted anyway, and you should watch the first part of the scan closely, when it says “Preparing …” to see if it gets stuck in any potentially problematic folders. I could get a better idea of what might be causing this issue if you could send me a screenshot of the scan in progress, especially after it has go on for a while. If the first scan is still going you should get a screenshot of that now before you close it and restart the scan. You could also look in the error_log files on your server to see if there are any clues in there as to what is causing this slowness. Also check the Console tab in your browser’s Inspector to see if there are any error on the scan results page.

If you have any details that you want to share with me that might help me resolve this for you but you don’t want to post them on this public forum then you email me directly for more support with this issue.

eli AT gotmls DOT net

Yes, alternatively you could just add the cache folder to the list of directories to be skipped and the scan will simply skip that folder. Just type “cache” in that field on the settings page (no quotes).

Keep in mind that will leave the cache folder as a potential place for malicious code to hide. Also, note that if you were to get some kind of infection then your cache might contain replicas of that script and should be cleared out anyway.

I have just verified that the current version available for download is the same code as when I released it. There is no malware in that code, so the plugin source has not been compromised. However, it is possible that the copy of the index.php file that you had in the folder public_html/wp-content/plugins/elisqlreports/ was somehow injected with malware on your server, maybe even before you tried to install my plugin, or this might have just been a false positive. Either way, I would love to take a look at the code that was in that file, and also any detailed reports from your hosting provider about what kind of threat they found in that file.

Can you please p=contact me directly and help me get in contact with the SiteGround support team that you dealt with on this issue?

eli AT gotmls DOT net

I released the update last week. Please let me know if there is anything else.

Thanks for sending me that code. I have confirmed that it is in fact a malicious threat and you should let my plugin perform the automatic fix or else just delete that whole folder off your server. If you delete it manually then make sure to get the file timestamps first (you will want to know when that file was last changed/modified.

The more important issue is to determine how that plugin got on there in the first place. You should check log files on the server to see if there was any suspicious activity at the exact time that this malicious file was installed (that is why your want to get the timestamps before deleting files). You should also check your WP Users page for any unrecognized users (especially administrators). If you have FTP logs then you can also check those for any connections that are unaccounted for and might have been used to upload this malware.

At this point it’s also a good idea to change all your passwords for all admin users, FTP user, control panel access, and any other means that you have of connecting to your server.

1. Without more info I can only assume that you must not have the “Database Injection” checked under “What to look for:”, but I cannot make any better guesses without seeing more of your setting. Your screenshots are so specifically cropped in on a very small section of the screen that there is not enough data for me to determine anything other than that does appear to be skipping the Database.
2. That is weird indeed. Given the assumption from Question #1 I would be inclined to suggest the possibility that you have not download any of the definition updates and are possibly only scanning for “Potential Threats”. If this is the case than you need download the latest definition updates and then run another Complete Scan with all the categories in the first column check, then I would bet that it will find this undetected threat. If not then please send me as much data about the scan setting and all the results from that scan, as well as any known info about this infection or any affected files that you have found.

You can also contact me directly with any data that you feel is too personal to share on this public forum:

eli AT gotmls DOT net

Hi Andy,

I fixed that error on line 823 by changing:

            if ($GLOBALS["ELISQLREPORTS"]["settings_array"]["menu_display"] || ($_GET["page"] == $Rslug))

to:

            if ($GLOBALS["ELISQLREPORTS"]["settings_array"]["menu_display"] || (isset($_GET["page"]) && $_GET["page"] == $Rslug))

… but I have not released the update yet because I am still working on another feature which I think you could use to get the same effect as a confirmation control. I am adding an optional password protection feature for each report that can be set and applied individually and would thus require the end user to perform an additional step before the report is executed. I suppose you could publish the password on the page with the report if you wanted anyone to be able to unlock it and that extra step would prevent the report from running until it was confirmed with the password. What do you think, would that be useful to you?

If you just need the fix for the error you initially reported to be fixed then you can make the change illustrated above to the plugins/elisqlreports/index.php file on line 823 in your current copy of the plugin and then update to the new release once I have finished and tested all the new changes.

I see the undefined array key, but I cannot recreate that error in my logs. Can you tell me what URL you are getting this error on and what version of PHP you are using?