_{As part of our cataloging the vulnerabilities in WordPress plugins for our service we come across false reports of vulnerabilities from time to time. So that others don’t spend their time looking over these as well, we post our findings on them.}

Yesterday a report of a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability in version 4.6.0 of the Newsletter plugin was released. The changelog noted a security fix in the version it was supposed to have been fixed in, but the wording seemed to downplay the claimed issue, as it said “Fixed a security issue on admin side only exploitable by logged in admins”. A cross-site request forgery vulnerability involves getting someone else to access a URL that causes them to send a request to their website, so if the vulnerability had existed, to say that it was only “exploitable by logged in admins” would have been true, but misleading, since it would not have required them to be trying to exploit the vulnerability. But as we quickly found, the misleading part was describing it as a security issue.

The report claimed that the issue was on one plugin’s setting pages, /wp-admin/admin.php?page=newsletter_subscription_lists. When we installed version 4.6.0 of the plugin and visited the page we found that the page contained nonce input in the form that was supposed to have the cross-site request forgery issue. So either the nonce was not being properly checked when the request was submitted or the report was false. A quick checked showed that when an invalid nonce or no nonce was include the request was properly rejected.

A closer look at the report showed that the proof of concept for exploiting this included a nonce as the second input:

act=save&btn=&_wpnonce=7cad5407b5

So the person reporting this must not have understood that what that was and that its presence meant that cross-site request forgery was not possible and therefore no vulnerability. The changes made in version 4.6.1, which they claimed fix this, confirm that, as no changes were made related to CSRF protection. The changes instead related to escaping some values, but as the settings page is only accessible by Administrators and they normally have the unfiltered_html capability, their use of the equivalent of cross-site scripting would normally be permitted, so the issue would be better described as a bug.