The wp core verify-checksums command checks whether the WordPress core files have been modified or corrupted. The warnings indicate that some files that should not exist in a standard WordPress installation are present.
The warnings about files in the wp-includes/ and wp-admin/ directories (wp-includes/error_log, wp-admin/error_log, wp-admin/images/Thumbs.db, and wp-admin/php.iniCZ) should be investigated, as they suggest that there may be some issues with the installation. The error_log files could contain information about errors on the site that should be addressed, while the other files may indicate that there are additional files or directories that have been added to the installation.
It’s possible that some of the other warnings about files that should not exist (wp-rss.php, wp-commentsrss2.php, wp-pass.php, wp-rdf.php, wp-feed.php, wp-register.php, and wp-rss2.php) are false positives, but they should still be investigated to ensure that there are no unauthorized or malicious files on the site.
It’s recommended that you investigate the presence of these files and take appropriate action to address any issues that may be present.
For me, the false positives are the entire issue. Is the tool at fault? Is it my configuration or use of the tool?
Automation means never having to chase false positives, eh?
If the files flagged as false positives are not causing any issues on your sites and you’re confident they are not malicious, you can consider them safe to ignore.
The wp core verify-checksums command is designed to be very strict in its verification process, ensuring that the WordPress core files match the original checksums provided by WordPress.org. As a result, it might flag files that are not part of the default installation, even if they are not causing any problems or security issues.
It’s not necessarily the tool that’s at fault, nor your configuration or usage. The command is simply performing its function to verify the integrity of the core files, and it reports anything that doesn’t match the expected files. False positives can happen due to various reasons, such as customizations, additional files, or temporary files created by certain processes.
If you’re sure that the flagged files are not causing any issues or security risks, you can ignore these warnings. However, it’s always a good idea to keep an eye on any unexpected files or changes in your WordPress installation to ensure the security and integrity of your sites.
In the case of automation, you may want to adjust your processes or tools to take into account the specific configuration of your sites and the expected files that may be flagged as false positives. This way, you can focus on addressing genuine issues and minimize the time spent on dealing with false positives.
I have finally found an old old thread which, even then, refers to these files as “ancient but for backward compatibility.”
The tool should either flag them as unnecessary or not flag them at all. If all the updates over the past 10+ years haven’t removed them, the tool should take that into account and, perhaps, flag them as “deprecated, can be safely deleted.”
Off to 1) delete them from my installs and 2) create a pull request for said change.
