Plugin Vulnerabilities

We recently ran across a WordPress plugin developer claiming that a security partner was ensuring their plugin was secure. We had run across the plugin because the developer had continued to use a known vulnerable third-party library for 21 months. It turned out to not be the only known vulnerable library in the plugin. There also is an additional unfixed security issue caused by the security partner, Patchstack, failing to make sure a vulnerability was properly fixed or to provide the information needed for others to vet their false claim it was fixed. They are hardly the only plugin developer claiming that their plugins are secure. Can you trust their claims?

One way to try to determine the answer to that would be to look at the evidence they providing to back the claims up. But they don’t provide any. For example, the developer of the 80,000+ install WP ULike provides this information in a FAQ in response to the question “Is WP ULike secure?”:

Yes, developed by TechnoWich, WP ULike follows the latest security and coding standards, with over 80,000 active users and a high WordPress rating.

The install count and rating don’t have any stated connection with whether it is secure or not. They do claim to follow “the latest security and coding standards,” but provide nothing to support that.

You can get an incomplete automated independent assessment of the handling of the security of WordPress plugins with our Plugin Security Scorecard. Somebody did that today with this plugin (which led to us noticing the security claim by the developer), the tool identified multiple issues with the plugin:

One of them involves the developer misusing a security function, which disputes the claim they follow security standards. Specifically, they are using the PHP filter_input() security function without specifying a filter, so it doesn’t provide any security. Looking at the code in question, there isn’t a vulnerability, as the misused function isn’t actually needed:

149

$isUsingCloudflare = !empty(filter_input(INPUT_SERVER, 'CF-Connecting-IP'));

Another identified issue involves usage of a WordPress function, maybe_unserialize(), known to be insecure, where the response from WordPress to securing it has been to suggest that plugins don’t use the function instead of fixing it. That doesn’t seem a like a good response, but using it in spite of that in the plugin doesn’t seem to be in line with following security or coding standards.

As an automated tool, the Plugin Security Scorecard is limited in what it can check for, but considering the issues it identified with the plugin’s code and that the developer isn’t providing the results of a security review of the plugin, it wouldn’t be surprising that there are more issues. And there are. One example highlights that the plugin is missing some basic security, which gets close to a serious security vulnerability.

In the file /admin/settings/functions/actions.php, the function ulf_import_ajax() is made accessible to anyone logged in to WordPress through its AJAX functionality:

123

add_action( 'wp_ajax_ulf-import', 'ulf_import_ajax' );

The code in the function is missing a basic security check:

99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122

  function ulf_import_ajax() {
 
    $nonce  = ( ! empty( $_POST[ 'nonce' ] ) ) ? sanitize_text_field( wp_unslash( $_POST[ 'nonce' ] ) ) : '';
    $unique = ( ! empty( $_POST[ 'unique' ] ) ) ? sanitize_text_field( wp_unslash( $_POST[ 'unique' ] ) ) : '';
    $data   = ( ! empty( $_POST[ 'data' ] ) ) ? wp_kses_post_deep( json_decode( wp_unslash( trim( $_POST[ 'data' ] ) ), true ) ) : array();
 
    if ( ! wp_verify_nonce( $nonce, 'ulf_backup_nonce' ) ) {
      wp_send_json_error( array( 'error' => esc_html__( 'Error: Invalid nonce verification.', 'ulf' ) ) );
    }
 
    if ( empty( $unique ) ) {
      wp_send_json_error( array( 'error' => esc_html__( 'Error: Invalid key.', 'ulf' ) ) );
    }
 
    if ( empty( $data ) || ! is_array( $data ) ) {
      wp_send_json_error( array( 'error' => esc_html__( 'Error: The response is not a valid JSON response.', 'ulf' ) ) );
    }
 
    // Success
    update_option( $unique, $data );
 
    wp_send_json_success();
 
  }

That missing security check being a capability check to limit what WordPress users can access the function. The code allows anyone who has access to a nonce, which is intended to prevent an attacker causing someone else to take an action, to update arbitrary WordPress options (settings). There is almost no situation where a plugin should have code allowing to update arbitrary settings, as that could allow an attacker to take control of a website. Instead, the developer should only allow certain options to be updated.

So who has access to the nonce? As far as we can tell, no one. As the code that generates that doesn’t appear to be used in the plugin. It looks to be connected to the paid “Pro” version of the plugin. So the insecure code really shouldn’t be in the plugin.

If an attacker logged in to WordPress could find another security issue that allows them to generate the needed nonce, they could, among other things, takeover the website.

Properly Assessing WordPress Plugins’ Security

The best way to assess the security of a WordPress plugin is a security review. Well, assuming the entity doing the review is really doing a security review, which isn’t always the case. If a developer is telling you their plugin is secure, they should be able to provide the results from a recent review to support that.

If a security review hasn’t been done, then our Plugin Security Scorecard can provide a much more limited assessment of the plugin’s security.