10 Jan

WordPress Plugin Security Review: WordPress Notification Bar

Recently we started reviewing the security of the WordPress plugins we use, and for our third review we had checked over the security of the plugin WordPress Notification Bar.

If you want a security review of plugins you use, when you become a paying customer of our service you can start suggesting and voting on plugins to get security reviews from us. 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 1.3.9 of WordPress Notification Bar. We checked for the following issues during this 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 are a common source of disclosed vulnerabilities these days)
  • 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 found a couple of really minor issues. After we notified the developer of the results they replied the same day that changes would be made in relation to those, though in the week since then that has yet to happen.

Lack of Capabilities Check When Resetting Settings

The plugin has a function reset_defaults(), which is accessible to anyone as it runs during admin_init, so it should check to make sure the request the reset is coming from a user with the proper capability. The function does check for a valid nonce, so in normal circumstances it shouldn’t be possible for those without the proper capability to get access to a valid nonce, but that shouldn’t be relied on alone.

Somewhat oddly the while the reset capability has existed since the first version of the plugin, the code that would provide the frontend for that has been commented out since the first version as well, so it has never been accessible through normal usage of the plugin. In the developer’s response they mentioned that they had removed that due to the limited number of settings.

Lack of Protection Against Direct Access to PHP Files

The plugin’s .php files lack code at the beginning of the files to restrict direct access to them.  We didn’t see anything that could be exploited in the files without the restriction in place.