Every time you add additional code to a WordPress plugin (or any other software) you are adding more potentially insecure code. That includes third party libraries and other third party code. Earlier this week we looked at the details of a local file inclusion (LFI) vulnerability in the Booking Calendar plugin caused by its use of a file from another plugin (interestingly the vulnerability doesn’t look like it was every exploitable directly in the other plugin). In that case the file had not been updated in Booking Plugin after it was initially introduced in to it, so while the original plugin’s code had been fixed 5 years ago, Booking Calendar remained vulnerable until weeks ago, which seems like a good reminder to keep third party code up to date.
While making sure that third party code in a plugin doesn’t contain any vulnerabilities would be rather difficult, something we ran across recently does seem to be an easy way to reduce the security risk that come from including them. While doing a security review of the plugin BackUpWordPress, which was selected to have that done by our customers, we found that the plugin had a minor vulnerability, a full path disclosure vulnerability. What is relevant here is that the file with the vulnerability was a testing file for a third party library included with the plugin, which didn’t appear to being used in the plugin. Testing files for third party libraries shouldn’t be something that normally is included in a plugin, since they won’t normally be used in that context and if someone had a need for them they can always add them themselves.