Skip to content

Release Notes: Charitable 1.6.39 Patches a Security Vulnerability

charitable-1.6.39-release-notes

Earlier this week we released Charitable 1.6.39, which fixed a security vulnerability (among a few other fixes). Please update as soon as possible, if you have not already done so.

At the outset of this post, let me say that I am not aware of any sites using Charitable that would be vulnerable to this issue. We discovered this issue in-house and released a fix within a day of identifying the problem.

Who was affected?

If you are using Charitable, this vulnerability did not affect you unless:

  • You have removed some (not all) of the Charitable-specific capabilities added to the Campaign Manager or Administrator roles, or from specific users with those roles.
  • You have added some (not all) of the Charitable-specific capabilities available to the Campaign Manager/Administrator roles to another role (like Editor), or to a specific user.

Changing the capabilities assigned to a specific role or a specific user is not possible with WordPress by default, but is is possible to do it with a number of different plugins.

What was the vulnerability?

This vulnerability is specifically related to the roles and capabilities added by Charitable.

Understanding Charitable roles & capabilities

Charitable core registers two user roles, one of which is the Campaign Manager role. This role has a set of capabilities that control what Campaign Manager users are able to do.

The capabilities available to the Campaign Manager include all of the capabilities available to Editors, as well as a set of capabilities that are added by Charitable:

  • view_charitable_sensitive_data
  • export_charitable_reports
  • edit_campaign
  • read_campaign
  • delete_campaign
  • edit_campaigns
  • edit_others_campaigns
  • publish_campaigns
  • read_private_campaigns
  • delete_campaigns
  • delete_private_campaigns
  • delete_published_campaigns
  • delete_others_campaigns
  • edit_private_campaigns
  • edit_published_campaigns
  • edit_donation
  • read_donation
  • delete_donation
  • edit_donations
  • edit_others_donations
  • publish_donations
  • read_private_donations
  • delete_donations
  • delete_private_donations
  • delete_published_donations
  • delete_others_donations
  • edit_private_donations
  • edit_published_donations
  • manage_campaign_terms
  • edit_campaign_terms
  • delete_campaign_terms
  • assign_campaign_terms

Note: All of the capabilities above are also added to the Administrator role.

Who is affected by the vulnerability?

To reiterate: when a user has all or none of the permissions above, there is no problem. This will be the case for most sites using Charitable.

However, if a site is modifying which capabilities are available to specific roles or specific users, there is the potential that users are inadvertently being provided with more information than they should be able to access.

Specifically:

  • A user with the edit_campaigns capability but without the edit_private_campaigns capability could still see private campaigns on the Campaigns page, though they could not edit these.
  • A user with the edit_campaigns capability but without the edit_others_campaigns capability could still see other users’ campaigns listed on the Campaigns page, though they could not edit these.
  • A user with the edit_donations capability but without the edit_others_donations capability could see other users’ donations listed on the Donations page, with links to view or edit them, though clicking on the link would result in WordPress informing them they lacked the required permissions.
  • A user with the edit_donations capability but without the edit_others_donations capability could create new donations for other users via the admin manual donation form.
  • A user without the export_charitable_reports capability with with the edit_donations or edit_campaigns capabilities could export the Donations or Campaigns reports.
  • A user with the view_charitable_sensitive_data capability but without permissions related to managing campaign terms such as manage_campaign_terms could still access the Campaign Categories and Campaign Tags pages and create/edit/delete terms.

If you know that you have made any modifications to how capabilities are allocated to different roles or specific users in your WordPress website, update to Charitable 1.6.39 as soon as possible.

Besides the issues noted above, Charitable 1.6.39 also resolved other issues related to having modified roles or user capabilities. For example, users with the view_charitable_sensitive_data capability but without the edit_campaigns capability would see a link to the Campaigns page in the WordPress dashboard menu, but would be denied access when clicking the link. The same issue existed for the Donations page for users without the edit_donations capability.

What else changed in Charitable 1.6.39?

The security fixes related to capabilities weren’t the only changes in Charitable 1.6.39. A number of other bugs were fixed, and one minor new feature was added:

  • New feature: Add CSS classes via post_class filter to target campaigns that have/have not reached their fundraising goal, or which have/have not ended. Issue #769
  • Fix: Donation Receipt & Donation Notification didn’t send when marking a donation as paid via the Donation Actions meta box or by editing the donation. Issue #771
  • Fix: Add default background color of white to the custom donation amount field to avoid issues where themes do not provide a color for the input field. Issue #766
  • Fix: Ensure that all campaign field values are correctly populated when viewing/editing a Draft campaign in the WordPress dashboard. Issue #763

Reminder: Update now

If you haven’t already, please go ahead and update your site to use the most recent version of Charitable now.

If you notice any problems related to this update, please get in touch with us via our support form.

Leave a Comment





[wpforms id="3080"]
[wpforms id="3080"]
[wpforms id="3080"]
[wpforms id="3080"]
[wpforms id="3080"]
[wpforms id="3080"]
[wpforms id="3080"]
[wpforms id="3080"]
[wpforms id="3080"]
[wpforms id="3080"]