For our 32nd security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin Post SMTP.

If you are not yet a customer of the service, once you sign up for the service as a paying customer you can start suggesting and voting on plugins to get security reviews. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our service.

The review was done on version 2.0.2 of Post SMTP. We checked for the following issues during as part of our standard review:

• Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
• Deserialization of untrusted data
• Security issues with functions accessible through WordPress’ AJAX functionality (those have and continued to be a common source of disclosed vulnerabilities)
• Security issues with functions accessible through WordPress’ REST API (those have started to be a source of disclosed vulnerabilities)
• Persistent cross-site scripting (XSS) vulnerabilities in the frontend portions of the plugin and in the admin portions accessible to users with the Author role or below
• Cross-site request forgery (CSRF) vulnerabilities in the admin portion of the plugin
• SQL injection vulnerabilities (the code that handles requests to the database)
• Reflected cross-site scripting (XSS) vulnerabilities
• Security issues with functions accessible through any of the plugin’s shortcodes
• Security issues with functions accessible through the admin_action action
• Security issues with functions accessible through the admin_init action
• Security issues with import/export functionality
• Security issues with usage of is_admin()
• Security issues with usage of add_option(), delete_option(), and update_option()
• Host header injection vulnerabilities
• Lack of protection against unintended direct access of PHP files
• Insecure and unwarranted requests to third-party websites
• Any additional possible issues identified by our Plugin Security Checker

We also checked for the following issues as part of looking into whether we should add them to our standard checks:

• Security issues with functions accessible through the admin_post action
• Usage of the extract() function

Results

We found a number of issues of various levels of concern, which are detailed below. The possibility of PHP object injection would probably be the most serious issue, but that being exploitable would depend on other software on the website. The one thing that would be classified as a vulnerability on its own is issues with cross-site request forgery (CSRF).  We notified the developer of the plugin of the issues Monday of last week, but we haven’t heard back from them and the plugin has yet to be updated.

The AJAX accessible functions registered through the function registerAjaxHandler() lack protection against cross-site request forgery (CSRF). Some of the functions, including sendTestEmailViaAjax(), definitely should have that and it wouldn’t hurt for the others to also have that.

In the function postman_fix_wpml() in the file /Postman/Postman.php runs during admin_init, so it is accessible to even those not logged in to WordPress. It looks like there should be a capabilities check to limit what users can access its functionality and a nonce to prevent CSRF before taking its action.

On the page /wp-admin/admin.php?page=postman_email_log, there isn’t protection against CSRF when using the Trash All logs button.

In the function view_log_item() in the file /Postman/Postman-Email-Log/PostmanEmailLogController.php allows viewing the content of any post, not just log items from the plugin. That isn’t an issue if only Administrators have access, but if lower level users were given the relevant capability to access that that would be a vulnerability. Along the same lines, it is currently possible to set malicious JavaScript code to the plugin’s settings, so it might make sense to make sure those validated, sanitized, and or escaped.

In the function postman_render_email_page() in the file /Postman/Postman-Email-Log/PostmanEmailLogController.php several user inputs are sanitized (on lines 364-366) using sanitize_text_field() and then output them as HTML attributes. That sanitization function isn’t designed for usage like that. Due to WordPress escaping quotes there doesn’t appear to be a vulnerability, but it would be better to escape those variables using esc_attr() instead of outputting the variables directly.

In the function resendMail in the file /Postman/Postman-Email-Log/PostmanEmailLogController.php and column_title() in the file /Postman/Postman-Email-Log/PostmanEmailLogView.php possible untrusted user input is passed to the function maybe_unserialize(). That function relies on the unserialize() function, for which the documentation warns about doing that, due the possibility of PHP object injection.

In the files /Postman/PostmanUtils.php and /Postman/PostmanWpMail.php the values of $_SERVER[‘HTTP_HOST’]
and $_SERVER[‘SERVER_NAME’] can be used to determine the domain name of the websites, that introduces security risk as those values come from user input and may not actually return the domain name. It might be better to rely on WordPress functionality to get the domain name.

On the plugin’s main admin page external servers are connected to for the loading of the PayPal logo and the Twitter feed. That would seem to violate the WordPress Plugin Directory guidelines, as guideline 7 states:

In the interest of protecting user privacy, plugins may not contact external servers without explicit and authorized consent.

Numerous .php files don’t have code at the beginning of them to restrict direct access to them. We didn’t see any security issues caused by that, but restricting access to them would insure that there isn’t any issue with that.

With the third-party libraries included the plugin it looks like there are files being included that are not actually needed, say this test file directory /Postman/Postman-Mail/sendgrid/vendor/sendgrid/sendgrid/test/. Removing those would reduce the size of the plugin and remove any security risk the files might pose.