When it comes to vulnerabilities in WordPress plugins, they often go unnoticed for years, as was the case with a vulnerability we ran across in WooCommerce this week. But with another situation in the last week, where an attacker was able to update plugins in the WordPress Plugin Directory to add malicious code to them, the situation was caught and addressed in the most popular plugins in 36 hours. Based on what we can determine so far, it appears the situation is one to learn from, but not a sign of a significant problem.

The Plugins

Looking at the five plugins lessens the concern here. The install counts are not too high for most of them. The most popular plugin has 30,000+ active installs according to WordPress and the least popular has 60+:

• Social Warfare: 30,000+ active installs
• Simply Show Hooks: 4,000+ active installs
• Wrapper Link Elementor: 1,000+ installs
• Contact Form 7 Multi-Step Addon: 700+ installs
• BLAZE Retail Widget: 60+ active installs

Only two of them seem supported anymore, based on the version of WordPress they are each listed as being compatible with:

• Contact Form 7 Multi-Step Addon: 6.5
• Social Warfare: 6.5
• Wrapper Link Elementor: 6.2
• BLAZE Retail Widget: 5.3
• Simply Show Hooks: 4.5

WordPress 6.5 is the latest version, which was released in April

Along those same lines, only two of the plugins had been updated in the last year before the malicious code was added:

• Contact Form 7 Multi-Step Addon: April 2024
• Social Warfare: April 2024
• Wrapper Link Elementor: April 2023
• BLAZE Retail Widget: March 2020
• Simply Show Hooks: October 2016

Even marking them compatible with a new version of WordPress would have required an update, so those others are not receiving basic support.

How The Hacker Could Update The Plugins

The underlying system that stores the files for WordPress plugins in the WordPress Plugin Directory is an Apache Subversion repository. Any changes made are logged, and the logging is publicly accessible. Through that, we could see that the account previously used to update the plugins was used to add the malicious code. Each plugin was updated with a different account, so the attacker had access to five accounts to accomplish this.

We don’t know how the hacker gained access to those accounts, but based on what plugins were modified, it seems highly likely the compromise wasn’t of the authentication system for the Apache Subversion repository

Considering that authentication only requires a username and password, there are multiple methods an attacker could have gotten access to the needed credentials. The same username and password are also used for logging in to the WordPress website. The methods the credentials could have been compromised includes malware on computers that had used the credentials, credentials that were reused across websites and another website was compromised, and the attacker buying the  credentials from another attacker that acquired them.

When the Hacker Gained Access

From the logging, it appears the attacker had access to the login to BLAZE Retail Widget on March 16. As there was a change made on that date with the updater logging it as “Recon”, with an empty file named “n.txt” added. None of the other plugins had changes that appear related to the attacker until June 21.

How it Was Caught

The first public mention of this that we are aware of comes from an employee of Automattic that states the WordPress.org Plugin Review Team was notified by an undisclosed individual of the issue with Social Warfare. (That person is one of the two Automattic employees that secretly joined that review team at some point.)

Quickly Caught

The logging for Social Warfare shows that the malicious code was added on June 22 at 4:15 AM and was removed the next day 4:55 PM by another member of the review team.

Considering that the attacker had access to another plugin months before this, it took them quite a while to try to exploit their access, and they were almost immediately caught.

The Code Doesn’t Use WordPress Functions

Looking at the malicious code added to Social Warfare, what immediately stands out is that a lot of code is used to create a new Administrator account on the website when it could have been done using a WordPress function and one line of code. There are at least several explanations for that. One is that the attacker isn’t all that knowledgeable about WordPress. Another is that way the code avoided any  plugin on websites that hooks into the normal process for creating an account, so it would avoid those logging or warning about the creation of the account. Yet another is that was done to try to avoid the code being detected.

They Left Debug Code In

In the code added to Social Warfare, there is this commented line in the code (which means it doesn’t run):

//$pattern = '/home/98752.cloudwaysapps.com/trnkgjmvur';

The variable set with that, $pattern, isn’t anywhere used in the code either.

That line also lists what appears to be the directory for a hosting account hosted with Cloudways. That possible is from a website the attacker has compromised as well. (We planned to contact Cloudways about that, but couldn’t find information on how to contact them about security issues.)

What Could Be Improved Based on This?

What happened doesn’t seem that concerning when you consider other problems with the security of WordPress plugins and how they are being handled (or more often not being handled), but what could be improved here? There are three areas that come to mind to us.

First, a more secure authentication system could be in place to make it harder for attackers to make updates to plugins. Options for that all have their own complications and considering the small size of the problem so far, it seems difficult to say introducing complications to stop this is worth the tradeoff. It would probably be a good idea separate from addressing this particular problem, though.

Second, considering that some of the plugins haven’t been updated in years, it might make sense to have new measures in place when it comes to updating long dormant plugins. Possibly requiring some additional step before they can be updated again or monitoring of the updates to them.

Third, better detection of malicious code being added to a plugin. The problem with doing that is malicious code can vary so much and since this isn’t a widespread problem, there are not a lot of examples that could be used to help flag it. If the plugins had been more popular or used by our customers, our own machine learning based system that tries to identify if updates to plugins fix or introduce vulnerabilities would have checked them., That would have flagged the malicious code updates as fixing vulnerabilities (clearly it doesn’t get things right all the time), but it would have led to us checking the changes and seeing what was really going on.

If you have other suggestions on what could be done to better handle this type of situation, comment below.

WordPress Should Do and Release an After Action Report

In past incidents where WordPress hasn’t handled malicious code and vulnerabilities in plugins well, there haven’t been any publicly disclosed reports on the situations from them. Based on the lack of concern that things went wrong, it seems unlikely that there was a private report either. Producing one on this situation would be helpful not only for the WordPress community, but the wider software space.

The reports being put out by the US government’s Cyber Safety Review Board are a good example of what that sort of report could entail.