In WordPress 5.0, which was released in December 2018, a new editor was introduced, known as the block editor or Gutenberg. In our latest test of WordPress security plugins to see if they can protect against vulnerabilities, we found no plugins provided protection against a vulnerability when exploited through that editor. Further testing confirmed that two of the plugins that would likely provide protection against that type of vulnerability did when using the Classic editor. The other plugins that would likely to provide protection didn’t provide protection even with Classic editor, but further testing confirmed that it also fails to provide the same protection with the Gutenberg editor that it would provide when using the Classic editor.

The type of vulnerability used in the test is being found in WordPress plugins quite often recently. It is an authenticated persistent cross-site scripting (XSS) vulnerability caused by a lack of proper security handling of shortcode attributes. That would allow an attacker to cause arbitrary JavaScript code to run on frontend pages of the website. These are not a serious issue, since the attacker would need be able to generate content that includes a shortcode, which would normally require access to a WordPress account that can create a post. Making those of more a concern though is that we have been finding recently that developers are failing in attempts to fix those, as we found, for example, with a plugin with 200,000+ installs. [Read more]

On July 22 a new version of the WordPress plugin uListing was released with a very concerning changelog entry:

• fixed: Unauthenticated Privilege Escalation for Registration

In looking into that, we found that what that referred to involved restoring a security check that had been removed in an earlier version. That a security check existed and then was removed is a bad sign for the security of the plugin, but it gets worse. While looking into that, we found that the change only addressed part of the privilege escalation issue in the plugin and new version of the plugin didn’t otherwise address the other part. We contacted the developer the same day, asking how we could report that to them. They only got back to us on Friday, though hopefully that can be resolved soon. [Read more]

As part of developing our upcoming firewall plugin for WordPress, we have implemented a feature to limit a hacker’s ability to exploit option update vulnerabilities. That is a type of vulnerability that allows a hacker to change arbitrary WordPress settings (options). This is a capability that has existed in the plugin NinjaFirewall for some time. Unfortunately, as we confirmed a couple of years ago, the developer overstated what was possible with it, claiming that it protected against the type of vulnerability, without qualification, when that wasn’t true. In reality, we found that it provided some protection, but not only was it limited in scope, it turned out the protection was easy to bypass by changing the option for the plugin’s settings, due possibly to protection not being fully thought through or due to offensive testing having not been done.

To make our feature as useful as possible, as many options that might be of interest to mass hackers as possible should be restricted being changed if the request to change them is not coming from a user with the manage_options capability. Finding out what existing security plugins were providing this type of protection would be helpful in doing that. Through our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities, we spotted an authenticated variant of that type of vulnerability in a plugin in May. That vulnerability still hasn’t been fixed as version 1.8.2.6, which was released yesterday. [Read more]