Problem with Checksum Hashes

I have own server and got same email. I’ve checked my WordPress with Wordfence plugin and got nothing. So I hope it is a false alert.

Actually, all our sites get the same. But once we turn on the automatic repair system and it replaces the files, the warnings go away.

For some reason, the index.php files all have different line-ending characters. Why is this? I don’t have an explanation for you. I have used the data coming straight out of the www.remarpro.com API. After testing I was tempted to exclude these index.php files, but I opted not to, since they could legitimately be used to host malicious code.

That all said though, I would definitely check your wp-includes/version.php file – that should definitely not be different to the original source.

My best advice here is to enable the automatic repair and the system will clean all this up for you and you wont get the notices again – except to say they’ve been replaced.

I think only www.remarpro.com could explain why all the index.php files that are shipped with their updates differ to the original coming out of the SVN source repository.

Got this message too, glad to see this explanation, BUT this should be reported as a bug report for WP.org then.

I’ve been digging in to what’s going on with a view to actually posting a bug.

It turns out, I believe that when WordPress introduced (years ago) patch upgrades for the WordPress core, they have built in a mechanism so that nothing gets upgraded that falls below the “wp-content” directory.

They since removed the ?> from the end of those index.php files meaning that they were never upgraded during WordPress upgrades. So if your site was installed before a given date, your files would have had ?> at the end and never been brought in-line with the latest versions of the files which don’t have the trailing ?>. ??

So, to fix the problem, simply remove the ?> from the ends of those files and/or enable the automatic repair option for the future.

I believe it’s worth to keep the checks on for the index.php files going forward and I don’t want to exclude them from the checks.

Thoughts?

Paul, isn’t it possible to exlude only that last small part (?>) from your checks, it is a bit of a hassle because then I have to change 30+ sites..

Same problem here: I am managing over 150 WPs for my customers and myself.
Having to manually correct each of them will take me for ages…

I’m working on an update to the plugin that will handle this special case. I’ll release it shortly…

Okay, I’ve released the update to address this issue, and a few others. v4.16.1

I had no idea you all has so many sites running the plugin.

Small question for you, how would integrating centralised management for this particular plugin into the likes of iControlWP control panel interest you? Would this be worth developing out for you guys?

That’s a great idea! I’m currently tied to InfiniteWP, at least for a while. Any chance of working it into that, also?

Thanks for the fast response and plugin updates, Paul. Getting our sites updated, now…

Thanks for the great plugin!

This issue is actually not resolved yet even though the plugin was updated.

I manage over 40 WP websites. Yesterday I installed the update meant to fix the checksum problem on all the sites. This morning I received 18 emails from 18 sites with this:

The MD5 Checksum Hashes for following core files do not match the official www.remarpro.com Checksum Hashes:
– wp-content/themes/index.php (www.remarpro.com source file)
– wp-content/plugins/index.php (www.remarpro.com source file)
– wp-content/index.php (www.remarpro.com source file)

and a couple of emails from another site that was just created a few weeks ago with this:

The following official WordPress core files are missing from your site:
– wp-admin/install.php (www.remarpro.com source file)

I think it might be a better practice when you roll out a new feature to not automatically enable it. Now I will have to manually login to over 40 sites to either disable the feature or to check the option for “Automatically Repair WordPress Core Files That Have Been Altered”

Thanks!

I understand the frustration here, but the only way to get a new feature to be used on any scale is to automatically enable it. With automatic updates, fixes can get rolled out relatively quickly.

It’s impossible to foresee such problems as this, where WordPress doesn’t actually keep these files up-to-date. And, their approach to multilingual WordPress is so messy it’s also throwing up version.php as a suspect file too because that’s used, in certain circumstances, to determine locale.

Doing new features like this is another reminder of how messy it all is.

I do apologise for the inconvenience of this, but having so many reports of issues actually allows us to better tweak the code more quickly to make it all the more better.

Thankfully nobody was locked out of their site; there were no horrific data corruption issues and no animals were harmed in its production. ?? Just lots of emails… no-one likes that, but I hope that most folk out there can see their way past that while it’s tweaked and refined.

Cheers!

I am also still getting warnings this morning.

I’m going to take a different view from others. I appreciate the great plugin, and an occasional issue like this is far better than my sites being compromised. I deal with almost 40 sites myself, and I would much rather have to go in and make individual setting changes than have you not keep making improvements to the plugin.

It’s not ideal, but far better than any worst-case alternative.

If you don’t enable new features automatically, then you will hear from a different group who have to go into dozens of sites manually to turn it on.

Thanks!

Okay, the next update will do the following:

– index.php will be replaced automatically when it’s discovered to be different in any way to the original source. If it is discovered to be missing, it will be treated like any other normal core WordPress file.

– version.php should now be detected correctly for non- English US installs

– wp-admin/install.php will now be ignored, only if it’s missing.

If anyone would like to do me a favour and test this, that’d be great!

Here is a how-to for the beta:
https://icontrolwp.freshdesk.com/solution/articles/3000046787

You can use the download zip link from here for the source:
https://github.com/FernleafSystems/wp-simple-firewall/tree/release/4.16.2

If testing betas isn’t your thing… you’ll need to hold on a day or so while I fully it test it further and anyone here provides feedback.

Thanks!

Just adding more grist to the mill here. I have over 90 WordPress websites that use this firewall. Love the plugin, however as with some other developers that add features into their products, I really do not want something that I have to go around every site and turn on/off because it is flooding me with emails because a new feature has been added. It is not a problem when you have a couple of sites. But for those of us that support lots of people it is a major issue. I have the index.php being reported from all locations. I also do not want to use iControl for security reasons. I am not implying it is insecure, however I do not want multiple methods of accessing all sites through one central console. So that is not a solution for me.
So if you add a feature into a plugin please do it quietly. Don’t add something in that sends out lots of messages. Because the only way to turn it off is to enter each site and change something. I do visit every site at least once every 3 months. At this time I could turn something new on, or generally review the plugins and make changes. Please do not misunderstand my comments, great plugin, great work, just bear in mind that there might be some heavyweight users out there, and not everyone has a couple of sites to tweak.