The WordPress security team has taken a rare step last week and used a lesser-known internal capability to forcibly push a security update for a popular plugin.
WordPress sites running the Loginizer plugin were forcibly updated this week to Loginizer version 1.6.4.
This version contained a security fix for a dangerous SQL injection bug that could have allowed hackers to take over WordPress sites running older versions of the Loginizer plugin.
Loginizer is one of today’s most popular WordPress plugins, with an install base of over one million sites.
The plugin provides security enhancements for the WordPress login page. According to its official description, Loginizer can blacklist or whitelist IP address from accessing the WordPress login page, can add support for two-factor authentication, or can add simple CAPTCHAs to block automated login attempts, among many other features.
SQL injection discovered in Loginizer
This week, security researcher Slavco Mihajloski disclosed a severe vulnerability in the Loginizer plugin.
According to a description provided by the WPScan WordPress vulnerability database, the security bug resides in Loginizer’s brute-force protection mechanism, enabled by default for all sites where Loginizer is installed.
To exploit this bug, an attacker can try to log into a WordPress site using a malformed WordPress username in which they can include SQL statements.
When the authentication fails, the Loginizer plugin will record this failed attempt in the WordPress site’s database, along with the failed username.
But as Slavco and WPScan explain, the plugin doesn’t sanitize the username and leaves the SQL statements intact, allowing remote attackers to run code against the WordPress database — in what security researchers refer to as an unauthenticated SQL injection attack.
“It allows any unauthenticated attacker to completely compromise a WordPress website,” Ryan Dewhurst, Founder & CEO of WPScan, told ZDNet in an email today.
Dewhurst also pointed out that Mihajloski provided a simple proof-of-concept script in a detailed write-up published earlier today.
“This allows anyone with some basic command-line skills to completely compromise a WordPress website,” Dewhurst said.
Forced plugin update receives public backlash
The bug is one of the worst security issues discovered in WordPress plugins in recent years, and it’s why the WordPress security team appears to have decided to forcibly push the Loginizer 1.6.4 patch to all affected sites.
Dewhurst told ZDNet that this “forced plugin update” feature has been present in the WordPress codebase since v3.7, released in 2013; however, it has used very rarely.
“A vulnerability I myself discovered in the popular Yoast SEO WordPress plugin back in 2015 was forcibly updated. Although, the one I discovered was not nearly as dangerous as the one discovered within the Loginizer WordPress plugin,” Dewhurst said.
“I’m not aware of any other [cases of forced plugin updates], but it is very likely that there have been others,” the WPScan founder added.
But there’s a reason why the WordPress security team doesn’t use this feature for all plugin vulnerabilities and uses this only for the bad bugs.
As soon as the Loginizer 1.6.4 patch started reaching WordPress sites last week, users started complaining on the plugin’s forum on the WordPress.org repository.
“Loginizer has been updated from 1.6.3 to 1.6.4 automatically although I had NOT activated this new WordPress option. How is it possible?” asked one disgruntled user.
“I have the same question too. It has happened on 3 websites I look after of which none of them have been set to auto-update,” said another.
Similar negative feedback was also seen back in 2015 when Dewhurst first saw the plugin forced update feature being deployed by the WordPress team.
WordPress core developer Samuel Wood said this week the feature was used “many times” but did not provide details about other instances where it was used. In 2015, another WordPress developer said the plugin forced update feature was used only five times since it launched in 2013, confirming that this feature is only used for the critical bugs only, those impacting millions of sites, and not just any plugin vulnerability.