_{From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.}

We often find that the various things that we do come to together to help improve each other and that came in to play with our confirming that a vulnerability had been fixed in version 1.12.26 of Form Maker (Form Maker by WD). One of the changelog entries for that version is “Fixed: Vulnerabilities reported by Neven Biruski from DefenseCode (using the tool ThunderScan).”. Nearly two weeks later DefenseCode has yet to put anything about what those vulnerabilities might be.

Looking at the changes made in that version there were a number of security related changes made, so to try quickly determine if there were an actual vulnerabilities fixed in that version we ran the previous version through our Plugin Security Checker tool. Interestingly it identified a possible reflected cross-site scripting (XSS) vulnerability based on an improvement we had made several weeks ago to the tool based on a vulnerability that we had identified while looking into whether an update to a plugin had fixed a vulnerability. A quick check confirmed that vulnerability was in fact exploitable and had been fixed in 1.12.26. Considering that Form Maker has 100,000+ active installs, it is another reminder of the poor state of popular plugins as an automated tool is able to catch security issues in them.

What the tool identified is that on line 193 of the file /admin/views/Themes_fm.php the value of the GET or POST input “pagination” is set to the value of the variable $pagination without being sanitized:

$pagination = isset($_REQUEST["pagination"]) ? $_REQUEST["pagination"] : 'none';

and then is output on line 308 without being escaped:

<div class="pagination-type" ng-init="pagination='<?php echo $pagination; ?>'">

That code is run when editing one of the plugin’s themes in the admin area of WordPress by and access to that is restricted to those with the manage_options capability, which would normally only be Administrators.

In version 1.12.26 line 193 has been changed to:

$pagination = WDW_FM_Library::get('pagination', 'none');

That causes the value to be sanitized using the esc_html() function.

Proof of Concept

The following proof of concept will cause any available cookies to be shown in alert box, when logged in to WordPress as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

Make sure to replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/admin.php?page=themes_fm&task=edit&current_id=1&pagination="><script>alert(document.cookie);</script>