On February 8 a report of several vulnerabilities in CodePeople’s Booking Calendar Contact Form plugin was released. While reviewing those for inclusion in our data we found that issue 5, a cross-site request forgery (CSRF) vulnerability that permitted the deleting calendar items still existed. That own its own is not major issue since someone would have to want to cause calendars to be deleted and get someone logged in as admin to visit a page that would caused it to happen, so we didn’t find much concern with that. We did notify the developer and several days later it was fixed.

While that on its own seems to be a minimal issue, over the next month vulnerability were reported in two more of the plugins and in each case CodePeople failed to fully resolve the issues, leaving us to believe the security of their plugins should be a concern.

Second Time

On February 24 a report of a session hijacking vulnerability in their Calculated Fields Form plugin was released. When we tested we found that a persistent cross-site scripting (XSS) vulnerability mentioned in that report still existed. We thought that maybe they were still working on fixing it, but we decided to notify them just in case they missed that.

The response we got back was odd:

The mentioned authenticated persistent cross-site scripting vulnerability cannot be considered a plugin vulnerability in this case but a WordPress feature: The WordPress posts and pages allow to paste <script> tags directly on them, so adding the script via the shortcode doesn’t add a new privilege since that privilege is already supported by the WordPress editor without needing a shortcode. The editors already have access to paste any scripts into the WordPress pages/posts.

It is true that editor level users are allowed to use unfiltered html by default, but that would seem to make this a bug not a feature in that cases, since it doesn’t seem to have been intended. The larger issue is that we had not said anything about editors (since we are aware of their capabilities) and the original advisory specifically mentions both authors and editors:

The attacker must have an account like author or editor for create posts and embed malicious shortcodes and hijack admin or other user’s sessions.

After we pointed out that it impacted authors as well, the issue was fixed.

Third Time

On March 2 a report of several vulnerabilities in their CP Polls plugins was released, including cross-site request forgery (CSRF) / cross-site scripting (XSS) vulnerability in the plugin’s import functionality. When we tested that we found that the CSRF portion of the vulnerability existed. So yet again that hadn’t resolved part of the issue and again the had failed to add CSRF protection despite the ease of doing it. By doing that they would prevent the possibility of similar issues since without the CSRF the other issues would not be exploitable. The importation of data into the website also seems like something that would be important to be properly secured to us.