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. [Read more]

One of the items we check for during our security reviews of plugins selected by our customers is to see if the plugin’s .php files can be accessed directly when they are not intended to. While being able to access them directly when that isn’t necessary usually doesn’t have any security impact, it is easy to prevent that from happening and it could in some cases prevent serious issues, like a remote code execution (RCE) vulnerability we found being exploited in a security plugin last year.

Something we ran across recently in our monitoring of security changes made to plugins, which allows us to include data on vulnerabilities that you won’t find in other sources of WordPress plugin vulnerability data, indicates that developers implementing such protection don’t always understand what it is that they are implementing. [Read more]