You’ll need to ask you hosting provider how you can modify your php.ini file. I depends on how the have PHP setup o n the server.
This is probably due to a memory_limit on your servere that is too small to scan these files successfully. Try increasing the memory_limit value in your php.ini file.
I am not aware of any conflicts between my plugin and any other plugin. If you find anything that does not seem to work right then please let me know and I can help you troubleshoot.
Thanks for posting this helpful code. As a shortcut you could just apply the patch, which would insert the whole Files tag, then you would just need to add the Allow lines for any domains and IPs you want to allow.
Right, so that False Positive was already corrected on the 5th of this month (after you ran that scan last month). It is now fixed so that if you restore that file from the quarantine and then run the scan again it will not flag it as a Known Threat.
Thanks for the entire file. I can see that this use of the eval function is not malicious but I also still don’t see this file detected as a known threat in my current definitions. Can you please click on the file name on the scan results page and then hover over the numbered link above the file contents so that you can see the name on the threat?
Then can you please send me this info or a screenshot of it, and also your definition version and your php version (found on the right-hand side)?
Two things: First, that line looks to be rem’d out and not used anyway, so it should probably just be removed; And second, this code by itself is not even detected as a Known Threat, so there must have been more code around this line that was a contribution factor in the identification of this threat.
Can you please send me this file in it’s entirety so that I can examine what caused it to be detected and update the definition if needed?
Please try deactivating my plugin for a few minutes while you test the theme compatibility. Once my plugin is ruled out as the source of the conflict then you can re-activate it and try others. Your site shouldn’t be too vulnerable if it is only turned off for a few minutes, it takes a long time for the Brute-Force attacks to have an affect on a server.
That’s great that you figured it out, and thank you so much for posting your solution here for others to see.
No, That error means that there is no response from your server when testing the session feature, it has nothing to do with any donations you have made. Check your server’s error_log files and ask your host to verify that sessions can be stored on your server.
First click “Get FREE Key” then just register that new key using the same email address that you used before. Both sites will then have their keys registered to the same account.
Thanks for posting this code to me. I have added this new variant to my definition updates.
My plugin does not write log “files” to your server. The closest thing to that would be the Scan Log on the bottom of the Scan Settings page, which just shows the prior activity of the plugin but without any details of the results of that activity.
I plan to have a more detailed Scan History feature in a future release but that is not in the plugin yet.
It looks like there is a corrupt file, maybe because only half of the malicious ode was removed. Chack the error_log files on your server to see which file is causing this 500 error and then I can help you fix or restore that file.
Actually, even Sucuri is saying that your site is clean now. You just needed to refresh their scan results after my plugin cleaned your site.
There is a link a the bottom of Sucuri’s scan results page that says:
*Cached results from 48 hrs ago. Force a Re-scan to clear the cache.
