In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use, we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports, we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular, are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to the level of getting their own post, we now place them in a weekly post when we come across them.

Stored Cross Site Scripting (XSS)  in Contact Form Email

With a claimed stored cross site scripting (XSS) vulnerability in Contact Form Email, the only information provide are these instructions:

1. Click Contact form to Email
http://192.168.111.129/wp-admin/admin.php?page=cp_contactformtoemail
2. Create new form name with <script>alert(1)</script>
3. Click Publish
4. XSS has been triggered
http://192.168.111.129/wp-admin/admin.php?page=cp_contactformtoemail&pwizard=1&cal=4&r=0.8630795030649687
5. Open a different browser, logged in with wordpress. Copy the URL and
Press enter. XSS will trigger.

The instructions don’t match with what we found when looking in to this. For example, there isn’t a button named “Publish”. What appears to be going on here though would involve accessing a page that is only normally accessible to users with the “edit_pages” capability:

488

add_menu_page( $this->plugin_name.' Options', $this->plugin_name, 'edit_pages', $this->menu_parameter, array($this, 'settings_page') );

They would normally also have the ability to do the equivalent of cross-site scripting (XSS).

While not really a vulnerability, the value in question shouldn’t contain JavaScript code, so sanitizing the value would be a good idea and the developer has done that.

Wordfence, WPScan, and Patchstack are claiming this is a vulnerability and it was fixed, but if it is a vulnerability, the issues hasn’t really been resolved, as on the same page the user is also able to “Add Custom Javascript”, where they can still do the same thing that is supposed to be the vulnerability here.