The WordPress security team took a step they rarely use last week, using little-known internal capability that allows forcing a security update for a popular plugin.
WordPress sites using the Loginizer plugin were therefore forcibly updated this week, with Loginizer version 1.6.4. This release contains a security fix for a dangerous SQL injection bug, which could have allowed hackers to take over WordPress sites using older versions of the Loginizer plug-in.
Loginizer is one of the most popular WordPress plugins today, with an install base of over a million sites. It provides security improvements for the WordPress login page. According to its official description, Loginizer can blacklist or whitelist IP addresses aimed at accessing the WordPress login page, add support for two-factor authentication, or add simple CAPTCHAs to block attempts to automated login, among many other features.
SQL injection in Loginizer
This week, security researcher Slavco Mihajloski found a serious vulnerability in this plug-in. According to the description provided by the WPScan WordPress Vulnerability Database, the security flaw lies in Loginizer’s brute-force protection mechanism, which is enabled by default for all sites where Loginizer is installed.
An attacker could have exploited this flaw to try to connect to a WordPress site using a specific WordPress username, in which it is possible to include SQL statements. When an authentication fails, the Loginizer plugin logs this failed attempt in the WordPress site’s database, along with the failed username.
But, as Slavco and WPScan explain, the plugin does not clean up the username and leaves SQL statements intact, allowing attackers to execute code on the WordPress database: security researchers point to this attack under the name of unauthenticated SQL injection. “It allows any unauthenticated attacker to completely compromise a WordPress website,” Ryan Dewhurst, founder and CEO of WPScan, told .
The latter also points out that Slavco Mihajloski provided a proof-of-concept script in a detailed report released earlier today. “This allows anyone with basic command line skills to completely compromise a WordPress site,” he adds.
The forced update of the plug-in does not make everyone happy
This vulnerability is among the worst security issues discovered in WordPress plugins in recent years. This is why the platform’s security team seems to have decided to force the Loginizer 1.6.4 patch on all affected sites.
Ryan Dewhurst tells that this “forced plug-in update” feature has been present in WordPress code since v3.7, released in 2013. However, it has only been used very rarely.
“A vulnerability that I myself discovered in the popular Yoast SEO WordPress plugin in 2015 has been the subject of this forced update. However, it was not as dangerous as the one discovered in the Loginizer plug-in, ”he adds. “I don’t know if there have been other cases [de mises à jour forcées de plug-in], but it is probable ”.
If the Wordpress team avoids using this feature, there is an explanation.
As soon as the Loginizer 1.6.4 patch started arriving on WordPress sites last week, users started complaining on its forum: “Loginizer has been updated from 1.6.3 to 1.6.4 automatically although I did NOT activate this new WordPress option. How is it possible ? Asks a disgruntled user. ” I ask myself the same question. This happened on three websites that I deal with, none of which has been configured for automatic updating, ”adds another.
Similar negative reactions were also seen in 2015, when Ryan Dewhurst first saw the WordPress team deploy a plugin’s forced update feature. The latter thinks that the feature is not more widely used because the WordPress team fears the “risk of pushing a bug patch to a large number of users”.
Samuel Wood, the main developer of WordPress, explained this week that this feature has been used “many times” but without giving more details on its other use cases. In 2015, another WordPress developer reported that the plugin’s forced update feature was used only five times since its launch in 2013, confirming that it is only used for critical bugs that affect millions of sites.