A couple of weeks ago we discussed our opinion that Automattic, the company closely associated with WordPress, should bear some of the responsibility for improving the security of WordPress plugins. That came up after we bumped in to their use of WordPress plugins for the WordPress.com VIP service, while trying track down the developer of a plugin to let them know of a security issue. It was only days later that we came across a closer connection between Automattic and the poor security of WordPress plugin.
As part of our efforts to improve the security of WordPress plugins we have created the Plugin Vulnerabilities plugin that alerts when the currently installed version of plugins have known security vulnerabilities (as well as listing vulnerabilities that existed in installed plugins). When we add vulnerabilities to the dataset for that plugin we verify that vulnerability exists and what versions it existed in, in some instances we have found that vulnerabilities that discoverer of the vulnerability and or the developer of the plugin claim have been fixed have not actually been fixed. That is the case with two reflective cross-site scripting (XSS) vulnerabilities recently identified in the Pods plugin. While the report says that the vulnerabilities were fixed in version 2.5, we found that they still existed in that version. While looking for a way to contact the developers to let them know that issue existed and had been publicly disclosed, we noticed that footer of the website prominently displays that the project is sponsored by Automattic:
According to their About page, Automattic has been sponsoring development since 2012.
After a little more digging we were able to find Pods recommend method for reporting a security issue. While we got a quick response it didn’t seem like they really understood things. In our initial contact we recommended they use Firefox when confirming the vulnerabilities still exist, due to XSS filtering in other major web browsers that would protect against the example exploits of the vulnerabilities that were provided in the advisory (the XSS filtering would not necessarily protect against more advanced exploits). In response they asked how they could confirm them in Chrome for some reason. A week later two new version, 2.5.1 and 2.5.1.1, were released that based on the changelog fixed a number of bugs, but did not fix the security vulnerabilities that have been publicly available since January 12. As of today the vulnerabilities still exist in the plugin.
In reviewing the other vulnerabilities that were included in that report another thing stuck out to us, the security of Pods has actually gotten worse over time. One of the other vulnerabilities could have lead to all the of Pods data being deleted from a website if a malicious actor could get a logged in admin to visit a specified page through a cross site request forgery (CSRF) vulnerability. That vulnerability existed back to version 2.0, but as of at least the last version of 1.x series the reset function was protected from this type of vulnerability with a nonce.