We have recently been testing to see if we can improve our ability to detect vulnerabilities being introduced and fixed in WordPress plugins using machine learning. One of our interests in doing that is so that we can better deal with situation where developers don’t disclose that they are fixing or attempting to vulnerabilities in their plugins. That appears to have happened with the version of one of the most popular WordPress plugins, Essential Addons for Elementor, which has 1+ million active installs according to WordPress, that was released yesterday.

One of the machine learning models we are testing flagged the changes to the PHP code being made in that as having fixed a vulnerability. There is a changelog entry that indicates that a security change was being made to the plugin:

Improved: Sanitized HTML Tags in the WooCommerce Widgets

But as we started reviewing the changes being made in the new version, we noticed a security change, which we confirmed had previously permitted a vulnerability to occur, that was unrelated to that. There is changelog entry that seems to be related to it, but it doesn’t suggest that the change was being made for security purposes:

Fixed: EA Flip Box | Title & Button links not working without “https://”

That the developer appeared not to understand the security implication of change being made is a bit concerning.

More problematically, we found that there still was another instance of the vulnerability.

Authenticated Persistent Cross-Site Scipting (XSS)

The security change involved changing two lines in the file /includes/Elements/Flip_Box.php to add URL escaping to them. Here is how one of the lines looked before the change:

1492

'href'  => $settings['flipbox_link']['url'],

And after:

1492

'href'  => esc_url( $settings['flipbox_link']['url'] ),

Adding escaping doesn’t necessarily indicate that things were insecure before, depending on what other security is occurring. So we tested things out to see what previously could occur. What we found was that previously it was possible to cause JavaScript code to be set as the link for the plugin’s Flip Box element if the link type was set to title or button.

For whatever reason, the other link type has code that looks different from the other two (and was already secured):

1476

$this->add_render_attribute('flipbox-container', 'href', esc_url($settings['flipbox_link']['url']));

We checked over the plugin for other instances of similar to code to both of those code formats and we found that there was still another instance missing escaping.

In the file for the Feature List element, /includes/Elements/Feature_List.php, there wasn’t escaping for links:

926

$this->add_render_attribute( 'eael_feature_list_link' . $index, 'href', $item['eael_feature_list_link']['url'] );

As the proof of concept below confirms, that allows those able to create posts to cause JavaScript code to run when clicking the link, which is an authenticated persistent cross-site scripting (XSS) vulnerability.

We notified the developer of that yesterday. Today they resolved the issue, but didn’t disclose that they were fixing a vulnerability:

Improved: Data escaping for Security Enhancement

The change this time involved changing to use a function from Elementor to handle things:

918

$this->add_link_attributes( 'eael_feature_list_link' . $index, $item['eael_feature_list_link'] );

Takeaways

This situation is a reminder of why it is a bad idea to selectively keep plugins up to date, as other WordPress security companies and journalist are often implying should be done by telling people to update specific plugins, instead of keeping them all up to date at all times.

It also is a reminder of the need to review security changes, as they often are incomplete. One problem with that is that competitors of ours claim to be doing that, despite it sometimes being obvious they haven’t. With our service we review all indications of security vulnerabilities being fixed in plugins used by our customers.

Proof of Concept

Create a new post and a Feature List element. Set the link of a feature item to:

javascript:alert(document.cookie);

When clicking on the link on the resulting page, any available cookies will be shown in an alert box.