The WordPress security team took a step it rarely uses last week, using a little-known internal capability that allows it to force a security update for a popular plug-in.
As a result, WordPress sites using the Loginizer plug-in were forcibly updated this week to version 1.6.4 of Loginizer. This version contains a security patch 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 plug-ins today, with an installation 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 aiming to access the WordPress login page, add support for two-factor authentication, or add simple CAPTCHAs to block automated login attempts, among many other features.
Table of Contents
SQL injection in Loginizer
This week, security researcher Slavco Mihajloski revealed a serious vulnerability in this plug-in. According to the description provided by the WPScan WordPress vulnerability database, the security flaw resides in the Loginizer brute force protection mechanism, which is enabled by default for all sites where Loginizer is installed.
An attacker could have exploited this vulnerability to try to log into a WordPress site using a specific WordPress username, in which it is possible to include SQL statements. Upon an authentication failure, the Loginizer plug-in records this failed attempt in the WordPress site database, along with the failed username.
But, as Slavco and WPScan explain, the plug-in doesn’t clean up the username and leaves the SQL statements intact, allowing attackers to execute code on the WordPress database: security researchers refer to this attack as unauthenticated SQL injection. “It allows any unauthenticated attacker to completely compromise a WordPress website,” Ryan Dewhurst, founder and CEO of WPScan, tells HT4WP.
The latter also points out that Slavco Mihajloski provided a proof-of-concept script in a detailed report published earlier today. “This allows anyone with basic command-line skills to completely compromise a WordPress site,” he adds.
Forced plug-in update doesn’t just make people happy
This vulnerability is among the worst security issues discovered in WordPress plug-ins in recent years. That’s why the security team of the platform seems to have decided to force the Loginizer 1.6.4 patch on all affected sites.
Ryan Dewhurst tells ZDNet that this “forced plug-in update” feature has been present in the WordPress code since v3.7, released in 2013. However, it has only been used very rarely.
“A vulnerability I discovered myself in the popular Yoast SEO WordPress plug-in in 2015 was 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’s likely.
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 was updated from 1.6.3 to 1.6.4 automatically although I did NOT enable this new WordPress option. How is this possible?” asks a disgruntled user. “I’m asking myself the same question. This has happened on three websites that I maintain, none of which have been configured for automatic update,” adds another.
Similar negative feedback was also seen in 2015, when Ryan Dewhurst first saw the WordPress team deploy the forced update feature of a plug-in. The latter believes that the feature is not more widely used because the WordPress team fears the “risks of pushing a buggy patch to a large number of users.”
Samuel Wood, the lead developer of WordPress, explained this week that the feature has been used “many times” but did not elaborate on its other use cases. In 2015, another WordPress developer recounted that the plug-in’s forced update feature had been used only five times since its launch in 2013, confirming that it is only used for critical bugs and that affect millions of sites.
