supahduck

For what it’s worth, I ran a traceroute from my home office (using a Starlink connection), and it pinged normally through to the Montreal-based colocation site where my provider has some of their server infrastructure. All IPv4 pings, all resolving to FQDN’s, and certainly nothing that would prevent the Wordfence instances from properly resolving client IP’s.

Like I said, everything was running fine for the last several years, with no major code changes on multiple sites other than regular plugin updates, until the last month and a half, which is when I posted here in the forums.

It should also be mentioned that not all of my sites on that server are experiencing this issue, so that further indicates that it’s a coding issue, rather than a physical network / server configuration issue.

Would love to figure this out, so please let me know how I can help. Thanks!

@wfphil, if I understand your response correctly, then I can confirm that my provider does NOT run any sort of proxy. The server I’m on is configured with a classic IPv4 address, and has been running just find until fairly recently (i.e. the last month and a half or so). I’m talking multiple years with the sites, all running Wordfence, and all running smoothy (and reporting blocked IP’s properly) until this 127.0.0.1 issue.

Something has changed in the WF code, and it’s making the WF plugin pretty much useless for one of its core functionalities.

I remain ready to provide your team with whatever information / logs / access you need to diagnose the issue further, as it seems that I’m not the only one. Multiple users across multiple distinct and different setups, all seeing the same issue? It definitely points to a WF code issue.

What’s the next step?

Starting to get really concerned at the lack of response.

Received this e-mail today:

As you can see, the number of attacks is escalating. Here is the WF Dashboard widget for that same website:

I’ve got four other sites that are showing the same types of issues, out of a total of 9 on that webserver. So it’s not consistent across all sites on that IP.

Can ***someone*** from WF respond, please? There are lots of us that are affected by this, and it would be nice to be able to move this forward.

@wfphil , the 127.0.0.1 entries in my sites’ blocklists are continuing to pile up, and exceed all other entries by several orders of magnitude (100:1 to 200:1), and I am concerned that my ability to properly manage attack vectors and actors is being compromised by the lack of information. Having most of my attacks registered as coming from ‘localhost’ pretty much nullifies the entire value of the Wordfence blocking capability, and I would have thought that the loss of a core capability would garner more attention than this.

Seeing as I’m not the only one having this ongoing issue, is it at all possible to get an update on what’s going on, and if there is a solution forthcoming?

@wfphil Any updates? Seems like this is a widespread problem…..

Do you require any additional information on our system configurations, perhaps?

@xiff , good to know that I’m not the only one! I haven’t heared anything back from the Wordfence team as of yet, but hoping they will respond soon, as the attacks continue across most of my sites.

Any updates on this unusual situation?

Diagnostic e-mail has been sent, Phil. Thanks for your prompt response!

It should be noted that IPv4 addresses are being properly identified and geo-located, although that doesn’t appear to be the majority of the attempts.

In all the years I’ve been using WF and WF Central, I haven’t seen anything like this. Other than regular WP and plugin updates, nothing has changed on my sites in terms of configuration, and I don’t run any plugins from third-party repositories.

Any guidance / advice you can offer is appreciated!

Running 15.6.2 on WP 5.6, PHP 7.4.13, and the same behaviour is occurring. Issue is NOT fixed by 15.6.2!

Thanks for the prompt response, and for your work to update the compatibility! Much appreciated! I’ll happily leave a positive rating. ??

= 2.40.1 – Jan. 25, 2020 =
* improved data sanitization

It appears that the patched version is live, and the plugin is no longer suspended. I’ve updated all my client sites.

In terms of subjectivity of disabling vs. not disabling, that’s based on a pragmatic assessment of other plugins in the WordPress space, that allow user submissions “from the wild”, as it were. Many recent vulnerabilities exploit weaknesses in user authentication/validation, along with improper input field sanitization. You can’t really blame us for being paranoid.

I’m glad that the fixed version is live, and that everyone has worked hard to fix the problem.

Now, do you mind telling us what all the hubbub was about? ??

Cristian,

We are all well aware of the timelines involved in managing security issues like this, that’s not the concern.

Our concern is the exposure to our clients’ sites, if there is indeed a remotely exploitable vulnerability. If it’s not in the upload functionality, then it’s not something we can manage through the plugin settings, and therefore our only real remedy is to disable the plugin completely until the update/patch is released. Obviously, this is going to have a non-trivial impact on the look/feel/performance of our clients’ sites, so if we’re going to take a drastic step like disabling the plugin, we’d like to know if it’s a reasonable response to the security exposure.

Normally, until updates/patches are released, it would be a best practice to share meaningful mitigation measures. The lack of guidance in this respect is concerning, as we are all feeling exposed at the moment.

None of us can afford to have our clients’ sites compromised or hacked. Is there nothing you can tell us in terms of mitigation strategies?

I would agree, Manni02, in most of the recent vulnerabilities in other plugins, it’s usually insufficient user validation checks (the dreaded isadmin() mistake), which allows all sorts of damage via malicious uploads.

Glad to see that WP/Cristian/Machothemes are being proactive about this. ??

Already running Wordfence on all my client installations, and user uploads are not permitted (just using the plugin to publish testimonials submitted out-of-band, not allowing “public” uploads).

If the attack vector is purely through the upload functionality, then I’ll just make sure that it’s locked down, until we get more info/updates.

Thanks, Manni02!

Given that the suspension is in regards to a potential security issue, would you recommend disabling the plugin for now, until an update is released?

Just trying to minimize security exposure for my clients.