To cover your points.
1) A scan result can only offer to repair or delete a file. Our plugin cannot repair the WordPress wp-config.php configuration file and replace it with an original copy of the file as it contains custom data such as your database credentials. Therefore it has to be cleaned manually. For the index.php file, the reason it can’t be repaired may be because you have file permission or file ownership problems on your web server and our plugin does not have write access. The attacker may have also modified file permissions and our plugin does not have write access.
2) Our plugin is the most popular security plugin for WordPress and has the most effective and comprehensive web application firewall for WordPress. You can read about our vulnerability and firewall research below and see if our competitors do the same level of research:
https://www.wordfence.com/blog/category/vulnerabilities/
I will explain in more detail some possible scenarios of how a hacker can gain entry and why a site becomes compromised – even if you are very meticulous at keeping your server software, WordPress, your active and inactive plugins and themes all up to date with the latest versions with security patches applied.
Some causes of a hack are impossible for any WordPress security plugin to protect against.
- If you are using a weak password for your hosting account control panel or FTP account then a hacker may gain entry this way, with full access to your site’s file system and database. The cause may have been a weak password being used for a WordPress admin account.
- You are storing unmaintained, unarchived backups of your site that are publicly accessible that contain exploitable vulnerabilities.
- You are hosting more than one PHP application in the same hosting account and an infection can spread from another application to this WordPress site. An example of another PHP application would be another WordPress website, a different content management system such as Joomla or Drupal.
- You have unmaintained or vulnerable 3rd party scripts installed in your hosting account. Examples would be the Adminer or SearchReplaceDB database management tools.
- A nulled theme or plugin with malware already pre-installed. If you paid for a theme or a plugin outside of the vendors website at a massively reduced price, that seemed too good to be true, then it is likely to be nulled.
- If you are using a shared hosting account a neighbouring account can be infected and spread an infection to this site.
- Your WordPress wp-config.php configuration file could be readable to the hacker, either directly via your hosting account, via a vulnerable plugin or via another hacked site on the same server.
- The hosting accounts on the server may not be properly isolated so the hacker has access to your database via another user’s database.
- The server software has vulnerabilities that allow the hacker to get root access – such as running an end-of-life version of PHP on the hosting server that has unpatched vulnerabilities.
There are some aspects of your site security that are completely beyond our control such as vulnerabilities on your hosting server as described above. Although very rare, for examples of hosting provider vulnerabilities please see these articles below:
https://www.wordfence.com/blog/2021/11/godaddy-breach-plaintext-passwords/
https://www.wordfence.com/blog/2021/06/service-vulnerabilities-shared-hosting-symlink-security-issue-still-widely-exploited-on-unpatched-servers/
https://www.wordfence.com/blog/2020/05/28000-godaddy-hosting-accounts-compromised/
https://www.wordfence.com/blog/2019/06/service-vulnerability-four-popular-hosting-companies-fix-nfs-permissions-and-information-disclosure-problems/
https://www.wordfence.com/blog/2018/02/service-vulnerability-nfs-permissions-problem/
You can clean the site yourself and patch the intrusion vector by following the steps in these guides. Note that the infection, or part of an infection, may be in a database table that Wordfence doesn’t scan and will require a manual database cleaning. Wordfence used to scan the whole database but we had to stop doing that as it was too unstable on hosting providers that restrict server resource usage too much:
https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence/
https://www.wordfence.com/help/scan/scan-results/
Useful links after you have completed your cleaning:
https://www.wordfence.com/blog/2017/04/20-minutes-to-secure-wordpress/
https://www.wordfence.com/blog/2018/10/php5-dangerous/ (important note – this is an old blog post from October 2018 but still very relevant)
https://www.wordfence.com/blog/2020/08/10-wordpress-security-mistakes-you-might-be-making/
https://www.wordfence.com/blog/2018/10/three-wordpress-security-mistakes-you-didnt-realize-you-made/
https://www.wordfence.com/blog/2017/06/wordpress-backups/
We also have an extensive Learning Centre here:
https://www.wordfence.com/learn/