Erik,
that’s a great suggestion. I’ll pass that suggestion on to the developers. However, I have to tell you that sometimes there are plugin authors who change whats in the repo without doing a proper release. So the plugin is version 1.0 and instead of making the change and releasing version 1.1, they just make the change. We see this a lot for readme.txt files, where they change compatibility notes.
I’ll forward the suggestion to the dev team. Thanks forhelping make Wordfence great!
tim
Hi Tim,
Thank you for your reply and for forwarding my suggestion. I would say the example you give would be an excellent occasion to issue a warning. If a plugin developer changes something in a plugin file and WF issues a warning that makes sense. I then can compare the files (great function!) and judge for myself if this is a threat or not. I think this wouldn’t conflict with my suggestion that WF should – if possible – compare the installed plugin files with the plugin files of the same version in the repository even when the installed version is outdated. However, that would require older versions to be available in the repository. I don’t know if they are.
Erik
WP Webbouw
This sounds like a good thing for another reason. This morning, I got email alerts from WordFence about WordFence itself. When viewing the differences:
Author: Wordfence Version: 5.2.7
vs
Author: Wordfence Version: 5.2.8
@iammarchhare That’s weird because we released an update to 5.2.8. Had you already updated?
tim
@WF Support: It is difficult to say. The update and the scan took place at roughly the same time. My educated guess is that there was a race condition resulting in bogus alerts.
Thats probably it then. You should go enter the lottery now, seeing as the odds you had both happen at once are pretty slim 🙂
Let me know if you see any other issues with that.
tim
Today WordPress 4.01 was released and on some of the sites I manage this minor update was automatically executed. This led to a couple of Critical Problem Alerts in my inbox from Wordfence, like this:
Alert generated at Friday 21st of November 2014 at 07:44:45 AM
Critical Problems:
* WordPress core file modified: wp-admin/css/deprecated-media-rtl.min.css
* WordPress core file modified: wp-admin/css/deprecated-media.min.css
* WordPress core file modified: wp-admin/css/install-rtl.min.css
* WordPress core file modified: wp-admin/css/install.min.css
* WordPress core file modified: wp-admin/css/login-rtl.min.css
* WordPress core file modified: wp-admin/css/login.min.css
* WordPress core file modified: wp-admin/css/wp-admin-rtl.min.css
* WordPress core file modified: wp-admin/css/wp-admin.min.css
* WordPress core file modified: wp-includes/css/admin-bar-rtl.min.css
* WordPress core file modified: wp-includes/css/admin-bar.min.css
* WordPress core file modified: wp-includes/css/wp-auth-check-rtl.min.css
* WordPress core file modified: wp-includes/css/wp-auth-check.min.css
This looks like a timing matter. First I thought the files have obviously been changed by the automatic core update, but Wordfence still compares them to the previous version. However, when I look at the List of Files Revised in the release notes https://codex.wordpress.org/Version_4.0.1 I don’t see the above mentioned files listed.
So what’s going on here? All the modified files WF reports are css files and the modifications are harmless. However, the fact that they have been modified poses the question where were they modified? Was it done by WordPress and did they accidentally forget to mark the files as modified? Or anything else? I’m puzzled. Are these false positives and if so, what is the cause?
Erik
We mirror the wordpress repository. I’m making a note to verify our repository updates the same time as WordPress’ does.
tim
Hi Erik,
I have a theory of why this may be happening. To be clear: Wordfence is version sensitive so we know which version of core you have (along with themes and plugins) and verify against the correct version.
If you are running a version of core that we don’t have in our repository, then we let you know with an error saying that you’re using a version of core that we don’t support. So you’ll see this if you’re running a Beta or Alpha version for example.
But that’s not what’s happening here.
I think what may have happened is that the websites this occurred on don’t get very much traffic. And the way WordPress scheduled jobs work, a website needs to get a “hit” or page-view before it will run any scheduled jobs.
So in this case the website got a pageview and that kicked off any outstanding scheduled jobs. Both the Wordfence scan and the upgrade (which is also a scheduled job) kicked off at the same time.
Then the core scan was running while the core files were being modified and so it alerted on some of the core files because it was halfway through the upgrade – meaning that half the core files were 4.0 and half were 4.0.1.
Does that sounds like it’s a possible explanation?
Regards,
Mark.
Hi Mark,
Actually, I don’t think your theory holds.
What was happening, as I wrote in my earlier post, is that the alerted modified files were not part of the updated files as listed on the wordpress.org blog. So there is no coïncidence, something else has modified these specific files (they are really modified) while it’s clear they are all harmlessly modified, so kind of false positive, as I get exactly the same warning on exactly the same files on at least 5 very different sites.
Question remains open.
Should I post some of the modifications here?
Best regards,
Erik
