Earlier today we were discussing an example of the problem with WordPress plugins not being kept up to date. Recently we have also been looking in to another example of that, which also shows the type of work we do to make sure our clients have the best data on vulnerabilities in WordPress plugins and also some of what developers have to deal with when it comes to claims of them in their plugins.

One of things we do to keep track of vulnerabilities in WordPress plugins is to monitor the Support Forum on wordpress.org for topics related to those. Recently we came across a thread for the plugin Spider FAQ that indicated there might be a vulnerability in it:

Today OpenBugBounty wrote us a mail, that we have a css vulnerability problem with the searchfield from Spider-Faq.

One resolution is, to filter some Signs in the Searchfield. Can anyone tell me, where the Searchfield is located and where we should enter the Filter for the Symbols?

That sounded like it was describing a reflected cross-site scripting (XSS) vulnerability in the plugin’s search functionality on the frontend of the website. When we went to check on that though we found that things seemed relatively secure. What seemed to be the relevant code escapes what is submitted to be searched for (in the form of POST input search) to prevent XSS:

<div align="right"><input type="text" class="search_keyword" id="<?php echo 'skey'.$faq->id ?>" name="search<?php echo $faq->id ?>" value="<?php if(isset($_POST['search'.$faq->id])) { echo $_POST['search'.$faq->id]; } ?>" />

It looks like it would be better to be using esc_attr() instead of esc_html(), but other than things seemed fine.

At that point we were not sure what was going on and we waited to see if any more information would be disclosed in the thread that might make things clearer (due to the terrible moderation of the Support Forum, we avoid participating in it at this time).

After a response from the developer, the original poster responded with additional information. What was helpful to us in that was that they listed the address where this was occurring. With that we tried to see what version of the plugin was being used on the website, since it could have been that a vulnerability had existed in older versions of the plugin.

We were quickly able to identify that the version of the plugin being used on the website was from the 1.0.x series. That series was indeed vulnerable to this issue, as there is no escaping when the search term is output:

<div align="right"><input type="text" class="search_keyword" id="<?php echo 'skey'.$faq->id ?>" name="search<?php echo $faq->id ?>" value="<?php if(isset($_POST['search'.$faq->id])) { echo $_POST['search'.$faq->id]; } ?>" />

Version 1.1, which fixed that, was released on November 19 of 2013. So the plugin hasn’t been updated in over four years on that website.

Proof of Concept

Submitting the following proof of concept as the search term on a frontend page for the plugin will cause an alert box with the number 1 to be shown. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

“><script>alert(1);</script>