TL;DR: There’s no security hole. Plugin developers can use a different filter, and we’ll consider updating WP Cerber.
Aren’t you a bit concerned that this hole didn’t exist until another plugin was activated? I mean, WP Cerber continues to work flawlessly, but the issue is that the other plugin isn’t functioning as it should, due to WP Cerber’s specific architecture. To me, the title of this topic sounds a little clickbaity. There’s no security hole. At least not in WP Cerber.Anyway, thanks for bringing this issue to our attention.
Regarding the authenticate
filter. This design decision is based on our 9 years of developing WP Cerber, which have shown that a significant amount of invalid data often passes through filter parameters. This usually happens because unskilled developers are trying to implement something sellable. It’s easy for an inexperienced programmers to hook into a WordPress filter and accidentally return invalid data to another filter in the chain. Ultimately, WP Cerber gets the blame because it’s a sophisticated and well-supported plugin. Customers come to us for help, not to those programmers, because the latter can’t offer professional support.
Another point is that, for many years, WP Cerber has been the only plugin on most websites handling user authentication and protecting WordPress against brute force attacks. Plugin conflicts like you’ve described have been incredibly rare, mainly because this area of expertise was once accessible only to a select few developers.
The issue with the authentication filter poses no more risk than the inability to use some features from other plugins. This is just a typical plugin conflict that led to unexpected results.
What’s the solution in this case? Learn WordPress hooks. There is another hook wp_authenticate_user
which can be used instead of one that is occupied by WP Cerber.
That’s a false statement. This doesn’t open any roads for brute force attacks. It is WP Cerber that has successfully protected and continues to protect websites around the word from millions of brute force attempts and other cyber threats over the past decade, even when the username is known. We’ve collected tons of data on how these attacks are mounted, and trust me, WordPress sites don’t get hacked just because “the attacker succeeds in avoiding IP blocking.” At least, not when WP Cerber is in place.
So, let’s get back to the main point: should we update our authentication filter? I think yes. However, we need to do it in a way that benefits both our customers and us by directing customers to the plugin that generates that WP_Error, rather than our support team.