_{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. The data on these false reports is also included in our service’s data.}

Recently several security related changes were made to the plugin WP Job Manager, while reviewing the changes we didn’t see anything that looked like it would relate to something that would be classified as a vulnerability and needed to be detailed and added to our data set. The cause for one of the changes clarifies that there really wasn’t a vulnerability in that case.

A report was released within the last day claiming that a persistent (also referred to as stored) cross-site scripting (XSS) vulnerability had been fixed in version of 1.26.2 of the plugin.

The first instruction in the proof of concept starts to point that this report might be false:

1.From 'Job Listings' menu select 'Add New'
  http://localhost/wordpress/wp-admin/post-new.php?post_type=job_listing

To exploit this you need to be logged in, which if you had to be logged in as an Editor or Administrator level user to access the page wouldn’t be a vulnerability normally since they have the unfiltered_html capability that allows them to do the equivalent of XSS.

We found the page is only accessible to Administrator level users, which beyond the unfiltered_html capability, normally have the ability to do almost anything, so for example, they would normally be able to modify a plugin’s code to remove any security checks.

The second instruction in the proof of concept is:

2.Enter this payload for title of job
  <script>alert('Ehsan Hosseini - Xss Stored')</script>

When adding a job, the page that comes up looks like the page that comes up when editing a post or page:

That gives a visual indication that plugin is likely using standard WordPress functionality for creating jobs, which would also indicate that it is probably using the standard WordPress security handling and therefore properly secured already.

After noticing that, we removed the unfiltered_html capability from Administrators in the install of WordPress we were using to test this out and found that if we tried the proof of concept the JavaScript code seen in instruction 2 was properly sanitized, so the plugin was already properly obeying the WordPress security model.

The change made to plugin related to this was to escape the job title using esc_html() in several locations,  which isn’t necessary, but doesn’t hurt to do.