Automattic

Security Plugins and Plugins by Automattic Haven’t Been Updated To List Them as Compatible With WordPress 4.8

Back on May 31 we received an email from WordPress.org asking us, as developers of several plugins, to make sure that the plugin were listed as being compatible with the then upcoming WordPress 4.8. The beginning of the message reads:

Hello, White Fir Design!

WordPress 4.8 is scheduled to be released on June 8. Are your plugins ready?

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.8. This information provides peace of mind to users and helps encourage them to update to the latest version.

As scheduled, that version was released on June 8.

While looking at something the other day we noticed that a security plugin had not been updated to list as being compatible with the new version. Looking at the plugins tagged security it turns out that many haven’t been two weeks after the release of that new version of WordPress. That doesn’t seem to be a great indication as to the state of security plugins, but more striking was that several of the most popular plugins tagged security that have not been updated come from the company Automattic, which is closely associated with WordPress.

First up being Jetpack by WordPress.com, which is tied with 6 other plugins for having the most active installs, 3+ million:

One of those other plugins with the most active installs is another Automattic plugin, which despite shipping with WordPress also isn’t listed with WordPress 4.8:

Getting back to the security tagged plugins, another Automattic plugin not listed as being compatible is VaultPress:

Among the other security tagged plugin that haven’t been updated to be listed as being compatible, you have iThemes Security:

You also have Sucuri Security, which still hasn’t even been listed as being compatible with WordPress 4.7, despite that being released in December:

The parent company of that plugin GoDaddy also hasn’t updated their other plugins to list them as compatible:

Also worth noting, considering SiteLock’s questionable involvement with WordPress, is the SiteLock Security plugin:

Automattic Helping Security Companies Peddle False Narrative of Brute Force Attacks Against WordPress Admin Passwords

Last week we looked at one example of the poor state of security information surrounding WordPress, security companies falsely claiming that brute force attacks against WordPress admin passwords are happening (and also offering products and services that are supposed to protect against that non-existent threat). That has negative impact on security since you end with a lot focus and concern on something that isn’t actually threat while other issues, like the poor state of WordPress plugin security, which actually leads to websites being hacked, don’t get the focus and concern they should and needs to get.

While security companies being part of the problem isn’t something that really surprises anymore, considering that most of them seem to either know and or care little about security, when other companies that you would expect to be better, are part of the problem, it is surprising to us. That brings us to the company closely connected to WordPress, Automattic, which has among their offerings the plugin Jetpack.

Despite the fact that brute force attacks simply are not happening, protection against them is prominently advertised feature of the Jetpack plugin. As can be seen on the plugin’s page on wordpress.org:

and on the features page on the plugin’s website:

It easy to think the public would be more likely believe that they were happening when they see that.

At the same time the Jetpack website provides further confirmation that brute force attacks are in fact not happening. Going back to our previous post, with a password made up of numbers and letters (upper case and lower case) that is six characters long, there are over 56 billion possible combinations. By comparison according to the website, Jetpack has only blocked over 1 billion attempts:

Jetpack has blocked over one billion malicious log-in attempts aimed at our users’ WordPress websites.

While that might be enough attempts for a brute force attack to succeed if they all occurred on one website, that is a cumulative total across possibly millions of websites and maybe for a period of over a year, so it shows that there are not even close to enough attempts for brute force attacks to be happening.

We hope that Automattic will become more consciousness of the impact they have on the security of WordPress going forward, because it would be a help to us and others that are trying to improve the situation.

Auttomattic Sponsored WordPress Plugin Pods Still Hasn’t Fixed Publicly Known Security Vulnerability After Two Months

In discussing how the security of WordPress plugins could be improved we have put forward that Automattic, the company closely connected with WordPress, should have some responsibility for that. With a valuation of over billion dollars they certainly have the financial wherewithal to bear the burden of some responsibility. Shortly after putting forward that idea that we came across a security advisory for multiple vulnerabilities in Pods, a plugin that Automattic sponsors.

When we checked on the vulnerabilities to add them to Plugin Vulnerabilities plugin we found that despite the advisory saying that they were fixed in version 2.5, that in fact two reflective cross-site scripting (XSS) vulnerabilities listed still existed. Three days after the advisory was put out, January 15, we notified the Pods developers that vulnerabilities still existed. We promptly received a reply from them, but it didn’t seem like they really understood the situation.

A week later versions 2.5.1 and 2.5.1.1 were released, neither of which addressed the security vulnerabilities.

On February 5 and 9 we received emails from the developers that the vulnerabilities would be fixed in version 2.5.2. That version has yet to be released and it has now been two months that they have knowingly left the vulnerabilities in the plugin. Maybe this will be a wake-up call to Automattic that plugin security needs to be taken more seriously and that they can start playing a constructive role by improving the security of plugins they sponsor.