Full Details about Pods 2.x Security Vulnerability Patched in Pods 2.4.2
Dear Pods Users and Developers –
We’ve discovered a security vulnerability in Pods that affects all versions of 2.0 and later. The vulnerability affects those using the Extended Users feature, and in certain situation allows unauthorized creation of new users. The vulnerability has been patched in version 2.4.2 and all previous versions of Pods 2.x. If you are running Pods 2.4.1 or below, you have two options:
- Upgrade to Pods 2.4.2
- Re-download the Pods version you are currently using from the version downloads list on our WordPress.org plugin page, we have patched all previous versions of Pods 2.x
If you are using Pods 2.0+ on a site, I recommend that you do this now, and then come back and finish reading the rest of this post.
Earlier Sunday, June 22nd, 2014, we discovered a major security vulnerability in Pods 2.x versions and immediately released Pods 2.4.2 to fix this issue. In the interest of full disclosure, and to impress upon you the importance of upgrading / updating your sites immediately I would like to take this opportunity to explain the issue in detail and what I have done to fix it.
In addition, we would like to offer you free migration assistance from Pods 2.x versions of Pods to Pods 2.4.2. There are no upgrade processes or complicated code changes required to update from Pods 2.0+ to Pods 2.4.2. For those running Pods 1.x, we want to also remind you that we continue to be available to help assist in upgrades from Pods 1.x to the latest version of Pods. You can apply for assistance with migration from http://pods.io/help/. If you need immediate assistance, please don’t hesitate to contact us via e-mail at email@example.com.
In all versions of Pods 2.x, previous to Pods 2.4.2 it is possible to use a Pods AJAX-based form to create or modify an item for a different Pod than the form was intended for. This is due to a vulnerability in how the form’s nonce, or security key, was validated.
In most cases, this is a minor problem, as all data submitted to the form is still passed through data sanitization. This means that this issue could not be directly used to insert malicious data into the database. However, if you have an Extended Users Pod this could be used to gain access as an administrator on a site.
This vulnerability was due to an issue validating the “security key” (nonce) that is used to secure form submissions using Pods forms. Unfortunately, our form’s security validation was producing a false positive and did not validate it against the pod it was being checked against, and it did not throw any errors to alert us to the unintended consequences. Our forms have been specifically designed to validate the user submitting them, the pod, the fields, and the item being created/modified. At first glance, the nonce would appear to work to anyone looking at the code, but close inspection found that there were two problems in how the security key was validated.
You can see the simple fixes I made for this issue, in this commit and another commit. I also just committed fixes for all 33 versions of Pods previous to Pods 2.4.2, so you may now re-download the version you are running and replace your plugin’s files with the latest patched version.
As an added benefit, if you’re running Pods 2.4.2, you’re only a small hop away from Pods 3.0, so when all of our great new features arrive, you will have zero headache upgrading to Pods 3.0 and taking advantage of Field Groups, Loop Fields, and much much more.
Getting the Word Out
We’ve worked with WPEngine in order to notify all of the site owners who are running the affected versions of Pods about this issue. We urge other hosts to do the same, if they have this capability. Our friends at various companies like iThemes are also looking out for their users and helping to spread the word.
Reporting Security Issues
We take all security issues very seriously on the Pods team. If you believe you have found a security issue with Pods, for the security of all users, I ask that you not publicly disclose the issue until we have had time to address it and get a fix out to the affected users. Instead, I ask that you contact our team directly at firstname.lastname@example.org. You may also choose to contact email@example.com in addition with any security concerns about Pods or any other plugins hosted in the WordPress.org repository.
We are currently in the process of arranging a full security audit done for Pods 3.0, so as to avoid any future vulnerabilities. We’ve also been combing through all of the code to ensure it is WordPress.com VIP compatible out of the gate, so we may be allowed as an official plugin option to WP VIP projects.
Please accept my sincerest apologies for having allowed this issue to occur. I hope that you will continue to trust Pods on your sites. Feel free to contact me via email firstname.lastname@example.org or consult with any members of our team in our irc chat (#pods on irc.freenode.net or http://pods.io/chat/).
Scott Kingsley Clark