mwrusnak

Yep — I don’t even have revslider, so I’m not worried about that part. It’s just that the original poster and I have seen Wordfence showing an error in our error_log files, and I found that it is when ajax requests are blocked, like the one above.

I think that Wordfence probably shouldn’t send the “unlock” message in response to ajax reqeusts, since real users wouldn’t be directly viewing ajax responses anyway — but if the plugin authors do want the message to be sent during ajax requests, Wordfence should make sure the core file containing wp_create_nonce() has been loaded before the message. (I assume that WP core isn’t fully loaded for each ajax request, which is probably the cause of the missing function.)

I started getting these messages in my error_log every couple of days now, too, even though in the current version of Wordfence, the wfUnlockMsg.php file is protected from direct access.

I was able to match the times in the error_log to blocked requests for admin-ajax.php, usually probing for the revslider flaw. In my access_log, I see requests like this:
"GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=..%2wp-config.php HTTP/1.1" 503 2042 "-" "Mozilla/5.0 (Windows NT 5.2; rv:2.0.1)"

… so the 503 probably means it was blocked using the Wordfence security network, but I think Wordfence tried to “include” the wfUnlockMsg.php file, even though this was an ajax request. It probably doesn’t hurt anything (other than logging the error message the original poster mentioned), but can the programmers take a look at it? I think there were a few other posts about this a while back, so maybe this was the cause for them too.

@mymothersdaughter: If you look at your list of installed plugins, do you see any plugins that are version “1.3.3” below the description? The problem might be that another plugin set a version number in your database, without specifying what it is for. I do see at least one non-free plugin that is currently version 1.3.3, called “Responsive Flip Book WordPress Plugin”, but I haven’t used it myself, so I can’t see if this is the problem. Unfortunately, turning a plugin off might not remove that record — but finding the version number would confirm that another plugin might have been the cause.

(I’m not affiliated with Sucuri, but I found this problem interesting.)

@yorman: In sucuri.php, in the function site_version(), it checks get_option(‘version’) first, then checks for wp-includes/version.php — my recent WP installs don’t have a ‘version’ record in the wp_options table, so maybe that was an older standard? (Unless it’s used in multisite, which I do not use.) If it checked version.php first, or if it used get_bloginfo(‘version’), that might solve the problem if this is caused by another plugin.

Edit: Sorry for interrupting — I didn’t see your newest post before I posted. But I hope this helps narrow down the issue!

I haven’t had this problem myself, but heard similar reports with other plugins reporting the wrong WordPress version a while ago. Are you running any other security plugins?

I can’t remember which one, but I know at least one security plugin has the option to show a random WP version (and unfortunately, they changed the version number internally, which could cause this warning.)

@monk3:
1 & 2 — For me, Wordfence has mostly been working well enough with automatic blocking, with the Wordfence security network turned on. (If you are familiar with your access_log files, you will see that when someone is blocked by the Wordfence network, it will have a 503 HTTP response.) I usually only block an address manually if I see it coming back for 20-30 minutes or more, just because it seems to end their request a little faster (probably due to other plugins not needing to do any processing). Usually, when I see an address repeatedly trying to log in that is obviously not a real user, I’ll block them permanently.

3 — I generally block them from accessing the site entirely, since I’m only manually blocking IP addresses that are obviously bad. I often see that their hostnames are hosting companies, which wouldn’t be a normal user anyway. In the site I’m working on, 90%+ of users are from one region, so the China and Russia IPs are very unlikely to be real users, too — so I’m typically not worried that I’ll be blocking people with dynamic IPs that might end up assigned to another real user, or people sharing an IP on public wifi — but that might be a consideration for you, depending on your site’s audience.

@monk3: That is actually normal in WHM — Wordfence can only monitor and control web traffic that is reaching the site that WordPress+Wordfence is installed on — usually under a single cPanel user you created, unless WordPress is installed as the main site.

The log message above mentions “(pop3)”, which means they’re actually trying to access email accounts, like a desktop mail client would, which doesn’t go through the web server software — so Wordfence cannot see that at all.

On a site I handle, we actually turned off pop3, because none of us need to use that to access email anyway. We use IMAP instead, and don’t get nearly as many attempts there. We still get a lot of access attempts on SSH and some on FTP though, which also cannot be addressed by Wordfence. cpHulk does do a pretty good job of protecting those services, though, assuming no one is using really bad passwords that would be guessed in a small number of attempts — our only problem is that large attacks can significantly slow down our server for a while.

Today’s update seemed to fix the whole problem for me.

I use WHM myself — where are the brute force attempts shown?

If it is under “cpHulk,” that is separate from your WordPress logins. cpHulk doesn’t monitor WordPress or any other software on your hosted sites — but it does protect WHM/cPanel logins, SSH, FTP, and possibly local mail accounts.

They have more detail here:
https://documentation.cpanel.net/display/ALD/cPHulk+Brute+Force+Protection

Hope this helps.

Looks like they are working on it, based on this item in github:

https://github.com/Yoast/google-analytics-for-wordpress/commit/ec1b43b9ac70611a1d0e15f235d4a584a3863fea

I don’t see anything about when the fix will be released though.

To clarify, all of my settings do save, except for the “Ignore Users” field, which becomes blank — and then I only get the on-page error message when I attempt to fill it in again and save without changing any other settings.

The problem seems to be with the “Ignore Users” field (which is submitted as an array, causing the error above on line 88) — when I make changes to that field, I get the same error, and the changes are lost. The field becomes blank even if it was previously populated.

In the settings page itself, I now also get an error at the top of the page, “There where no changes to save, please try again.” whenever I try to change that field.

I’m starting to see it again too — I think it may have originally happened when people could access wfUnlockMsg.php directly (loading the file when WP wasn’t loaded), but that file is now blocked by .htaccess in that folder, as long as the server is configured to respect all .htaccess files.

I noticed today that it happened at the same time as an access to admin-ajax.php was blocked by Wordfence (with a 503 HTTP status) in my access_log — it sounds like Wordfence may be trying to display that message when ajax requests are blocked. Bug?

I can confirm that the s2Member readme file was definitely a bit.ly link — I saw that one too.

Wordfence itself needs to use admin-ajax.php frequently to show progress without reloading the entire page — so Wordfence is working as it is supposed to — but the css file is definitely odd, so it caught my interest.

I thought in the initial log that you posted, that your browser was loading both files since the requests were from the same IP, but I tried out the link library plugin on a test server and found that the css is being read over the network by the server itself! It also appears in the logs on any other page that uses ajax, but most of those are less often. (If you sit on the plugins or users pages long enough, you should see it in the logs.)

Anyway, I tracked it down to the file “link-library-defaults.php” in the link library plugin — specifically, these two lines:

$stylesheetlocation = plugins_url( 'stylesheettemplate.css' , __FILE__ );
$genoptions['fullstylesheet'] = @file_get_contents($stylesheetlocation);


I don’t know if there is a reason that the author of the link library plugin does it that way, but if he/she can make the plugin read the file directly from disk instead, it would stop the extra hits to the web server and should be much more efficient.

I had a problem like this a long time ago, and I think it is caused by the option “Update interval in seconds” near the bottom of the Wordfence options page. Try changing it to 5 seconds, save the options, then go to any other Wordfence page, and see if the ajax requests in the logs are then spaced out by 5 seconds. (If you stay on the Options page after saving, that page would still be doing ajax requests at the original speed until you leave it and come back.)

I have had mine set at 5 seconds for a long time, and haven’t noticed any problems. I don’t use the Live Traffic view anymore, which is probably where the difference would be most noticeable.