PMPro Update 2.10.6

This update fixes an issue where sensitive customer information may have been stored in the checkout_request_vars order meta that PMPro stores at checkout when using the Stripe gateway with the offsite checkout option. This issue seems to only have affected a small number of sites with specific configurations. Even so, this update is shipped with code to detect and repair the issue. The information here will help you to tell if this issue affected your site, what to do if it has, and how this issue happened in the first place.

First, note that this issue will only have affected sites that are using the Stripe gateway, and only if you are using the option to process checkouts “offsite with Stripe Checkout”. If you are not using Stripe or not using the Stripe Checkout option, then your site was not impacted by this issue.

Further, there are only a couple of cases that we know of where PMPro would have incorrectly stored sensitive information at checkout.

(1) Sites that are using the Sponsored Members Add On and the sponsored_accounts_at_checkout option in the sponsored level settings may be accidentally storing the plaintext child account passwords in order meta.

(2) Sites that are using an out of date custom checkout page template, perhaps as part of a theme coded to support PMPro, may be accidentally showing the credit card fields at checkout even though checkout is configured to process at Stripe. In cases that we can’t reproduce, these extra credit card fields, if they aren’t breaking the checkout process entirely, may get stored in the checkout_request_vars order meta accidentally.

If you aren’t using Stripe, aren’t using Stripe Checkout, aren’t using Sponsored Members with the option to create child accounts at checkout, and aren’t using an outdated custom checkout template, then your site would not have experienced this issue.

Still, this update checks the order meta on all sites to see if any sensitive information was accidentally stored and if found, starts a process to scrub the sensitive data from the database. If such sensitive data was found (anything that looks like a password, or anything that looks like an unmasked credit card number) then you will see a notice upon upgrading to PMPro v2.10.6.

You can also navigate to Tools > Site Health > Info > Paid Memberships Pro in the admin dashboard and look for a section labeled “Cleaned Fields”. If you don’t see that label, then PMPro did not detect any issues on your site. If you do, it will contain information about what was found.

Again, this update will automatically scrub the sensitive information from your database. If there are more than a few orders like this on the site, it will prompt you to run an “update script”. You should run this from the WP admin dashboard.

If you are sure, by checking the PMPro section of the Site Health info, that your site was impacted by this issue, then you should consider the following:

1. Consider addressing any staging site or database backup that may contain the same sensitive information. You can (carefully!) discard your staging site and recreate a new one from the live site after the data has been scrubbed. You can (carefully!) make a new backup of your database after scrubbing the data and deleting any old backup that contains copies of the sensitive data.
2. Consider removing the checkout_request_vars order meta from your databases entirely. These values are only needed during checkout before the initial payment or subscription setup has fully processed. You can safely remove the user meta after that point (and we may do that in the future anyway). To do so, you can (carefully!) run the SQL query here once on your live or backup databases. Note however that any checkout currently in process will fail if the request var data is removed. You could limit the query to orders within a timeframe or ones that include AccountNumber in the meta_value or some other indication of sensitive data.
3. Consider contacting any user whose data was incorrectly stored this way. We cannot determine if this is the correct course of action for your business and website, but if others potentially had access to this data or you have other legal requirements, you may want to disclose this to your users. To find the users impacted by this issue, export your orders to CSV from the Memberships > Orders page in the dashboard. Then check for a cleaned_data_2_10_6 column and scan or filter for any order that includes data in that column.

Paid Memberships Pro has an action hook pmpro_after_checkout that is used by Add Ons, other plugins, and custom scripts to perform actions after checkout. Typically this hook fires onsite when the checkout form is submitted. With the offsite “Stripe Checkout” option for the Stripe integration, users are taken away from the WordPress site, and the pmpro_after_checkout hook actually fires while processing the webhook Stripe sends later after the payment is processed.

So, when using Stripe Checkout, the pmpro_after_checkout hook is run in the background on the server. To make sure checkouts that happen on site are the same as checkouts that happen at Stripe and are later finished via webhook, we store all of the fields at checkout into order meta and make them available to the webhook processor. This process was already coded to ignore sensitive fields at checkout like the user’s password or their credit card number, but in the few cases described above, these precautions were not enough to stop some sensitive data from being captured at checkout.

This latest update has further precautions to prevent this from happening in the cases described above or in other cases that may occur. If you have any questions or information about this issue, please contact us. As we learn more, we will share with our users.