Loginizer Plugin Gets Forced Security Update for Vulnerabilities Affecting 1 Million Users

WordPress.org has pushed out a forced security update for the Loginizer plugin, which is active on more than 1 million websites. The plugin offers brute force protection in its free version, along with other security features like two-factor auth, reCAPTCHA, and PasswordLess login in its commercial upgrade.

Last week security researcher Slavco Mihajloski discovered an unauthenticated SQL injection vulnerability, and an XSS vulnerability, that he disclosed to the plugin’s authors. Loginizer version 1.6.4 was released on October 16, 2020, with patches for the two issues, summarized on the plugin’s blog:

1) [Security Fix] : A properly crafted username used to login could lead to SQL injection. This has been fixed by using the prepare function in PHP which prepares the SQL query for safe execution.

2) [Security Fix] : If the IP HTTP header was modified to have a null byte it could lead to stored XSS. This has been fixed by properly sanitizing the IP HTTP header before using the same.

Loginizer did not disclose the vulnerability until today in order to give users the time to upgrade. Given the severity of the vulnerability, the plugins team at WordPress.org pushed out the security update to all sites running Loginizer on WordPress 3.7+.

In July, 2020, Loginizer was acquired by Softaculous, so the company was also able to automatically upgrade any WordPress installations with Loginizer that had been created using Softaculous. This effort, combined with the updates from WordPress.org, covered a large portion of Loginizer’s user base.

The automatic update took some of the plugin’s users by surprise, since they had not initiated it themselves and had not activated automatic updates for plugins. After several users posted on the plugin’s support forum, plugin team member Samuel Wood said that “WordPress.org has the ability to turn on auto-updates for security issues in plugins” and has used this capability many times.

Mihajloski published a more detailed proof-of-concept on his blog earlier today. He also highlighted some concerns regarding the systems WordPress has in place that allowed this kind of of severe vulnerability to slip through the cracks. He claims the issue could have easily been prevented by the plugin review team since the plugin wasn’t using the prepare function for safe execution of SQL queries. Mihajloski also recommended recurring code audits for plugins in the official directory.

“When a plugin gets into the repository, it must be reviewed, but when is it reviewed again?” Mihajloski said. “Everyone starts with 0 active installs, but what happens on 1k, 10k, 50k, 100k, 500k, 1mil+ active installs?”

Mihajloski was at puzzled how such a glaring security issue could remain in the plugin’s code so long, given that it is a security plugin with an active install count that is more than many well known CMS’s. The plugin also recently changed hands when it was acquired by Softaculus and had been audited by multiple security organizations, including WPSec and Dewhurst Security.

Mihajloski also recommends that WordPress improve the transparency around security, as some site owners and closed communities may not be comfortable with having their assets administered by unknown people at WordPress.org.

“WordPress.org in general is transparent, but there isn’t any statement or document about who, how and when decides about and performs automatic updates,” Mihajloski said. “It is kind of [like] holding all your eggs in one basket.

“I think those are the crucial points that WP.org should focus on and everything will came into place in a short time: complete WordPress tech documentation for security warnings, a guide for disclosure of the bugs (from researchers, but also from a vendor aspect), and recurring code audits for popular plugins.”