Over 40,000 WordPress Sites Affected by Privilege Escalation Vulnerability Patched in Post Grid and Gutenberg Blocks Plugin


📢 Did you know Wordfence runs a Bug Bounty Program for all WordPress plugins and themes at no cost to vendors? Through October 7th, 2024, XSS vulnerabilities in all plugins and themes with >=1,000 Active Installs are in scope for all researchers. In addition, through October 14th, 2024, researchers can earn up to $31,200, for all in-scope vulnerabilities submitted to our Bug Bounty Program! Find a vulnerability, submit the details directly to us, and we handle all the rest.


On August 14th, 2024, we received a submission for a Privilege Escalation vulnerability in Post Grid and Gutenberg Blocks, a WordPress plugin with over 40,000 active installations. This vulnerability can be leveraged by attackers with minimal authenticated access to set their role to administrator utilizing the form submission functionality.

Props to wesley (wcraft) who discovered and responsibly reported this vulnerability through the Wordfence Bug Bounty Program. This researcher earned a bounty of $1,127.00 for this discovery. Our mission is to Secure the Web, which is why we are investing in quality vulnerability research and collaborating with researchers of this caliber through our Bug Bounty Program. We are committed to making the WordPress ecosystem more secure, which ultimately makes the entire web more secure.

Wordfence Premium, Wordfence Care, and Wordfence Response users received a custom firewall rule to provide protection against any exploits targeting this vulnerability on August 28th, 2024. Wordfence free users will receive the same protection 30 days later on September 27th, 2024.

We sent the full disclosure details to the plugin’s author on August 28th, 2024 and, while they didn’t acknowledge the report immediately, they released a patch just a week after our disclosure on September 5th, 2024. We commend the team at PickPlugins for the quick remediation of this vulnerability.

We urge site owners running a vulnerable version to update their sites with the latest patched version of Post Grid and Gutenberg Blocks, version 2.2.91 at the time of this writing, as soon as possible.

Vulnerability Summary from Wordfence Intelligence

Description: Post Grid and Gutenberg Blocks 2.2.87 – 2.2.90 – Authenticated (Subscriber+) Privilege Escalation
Affected Plugin: Post Grid and Gutenberg Blocks
Plugin Slug: post-grid
Affected Versions: 2.2.87 – 2.2.90
CVE ID: CVE-2024-8253
CVSS Score: 8.8 (High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Researcher/s: wesley (wcraft)
Fully Patched Version: 2.2.91
Bounty Award: $1,127.00

The Post Grid and Gutenberg Blocks plugin for WordPress is vulnerable to privilege escalation in versions 2.2.87 to 2.2.90. This is due to the plugin not properly restricting what user meta values can be updated and ensuring a form is active. This makes it possible for authenticated attackers, with subscriber-level access and above, to update their user meta to become an administrator.

Technical Analysis

Post Grid and Gutenberg Blocks is a plugin designed to enhance and extend the native block editor of WordPress. One of its features is the ability to add forms through the block editor with several form types like survey, comment submission, and user profile editing to name a few.

Unfortunately, the functionality used to add custom user meta to the user profile editing form was insecurely implemented making it possible for users to supply arbitrary user meta keys and update their values, including the wp_capabilities key. This specific functionality was introduced in version 2.2.87.

Taking a closer look at the root of the problem, the plugin registers the function form_wrap_process_userProfileUpdate() that is used to process form submissions when the ‘formType’ parameter is set to ‘userProfileUpdate’.

add_filter('form_wrap_process_userProfileUpdate', 'form_wrap_process_userProfileUpdate', 99, 3);

function form_wrap_process_userProfileUpdate($formFields, $onprocessargs, $request)
{


  $response = [];

  $first_name = $request->get_param('first_name');
  $last_name = $request->get_param('last_name');
  $display_name = $request->get_param('display_name');
  $user_url = $request->get_param('user_url');
  $description = $request->get_param('description');
  $nickname = $request->get_param('nickname');
  $locale = $request->get_param('locale');
  $rich_editing = $request->get_param('rich_editing');
  $syntax_highlighting = $request->get_param('syntax_highlighting');
  $admin_color = $request->get_param('admin_color');
  $admin_bar_front = $request->get_param('admin_bar_front');
  $user_login = $request->get_param('user_login');
  $user_email = $request->get_param('user_email');
  $pass1 = $request->get_param('pass1');
  $pass2 = $request->get_param('pass2');

Further down in the function, the following code was present to retrieve the value of the user_meta parameter and then pass that data to the update_user_meta() function which will update a user’s metadata.

$user_meta = $request->get_param('user_meta');



      if (!empty($user_meta)) {
        foreach ($user_meta as $metaKey => $metavalue) {
          update_user_meta($currentUserId, $metaKey, $metavalue);
        }
      }

      $user_meta_files = $request->get_file_params()['user_meta'];

The vulnerability here is quite easy to understand. There were no restrictions or checks on the user meta keys or values being obtained from the ‘user_meta’ parameter meaning any key/value combination could be supplied. This makes it possible for authenticated users to supply the array wp_capabilities[administrator]=1 via the ‘user_meta’ parameter which will get saved in the database and update the currently authenticated user’s role to administrator.

In addition, the form functionality has no checks to verify that a form is active and what type of form is active, making it possible for this to be exploited on any instance running the plugin, even those without an active form.

As with all privilege escalation vulnerabilities, successful exploitation will lead to a complete site compromise. Once an attacker has access to an administrator account, they can further compromise the site by installing plugins or running arbitrary code through the plugin and theme editors.

💡Tip for Security Researchers Participating in our Bug Bounty Program

Keep an eye out for the function update_user_meta() when it accepts user input and no filtering is performed on the user meta keys that can be updated. When no filtering is present, you may be able to supply an array such as wp_capabilities[administrator]=1 which will get serialized and stored in the database as a:1:{s:13:"administrator";b:1;} effectively granting that user the administrator role.

This is a fairly common privilege escalation vulnerability often introduced by new functionality in plugins and themes, especially member registration and management plugins

The vendor patched this issue by giving site administrators the option to supply custom user meta fields to be updated and then cross-checking any attempts to update user meta against the set list.

https://plugins.trac.wordpress.org/changeset/3146752/post-grid/tags/2.2.91/includes/blocks/form-wrap/functions.php

Developer Tip: Always Limit User Meta Updates to an Allow-List of Keys

The most common reason this type of vulnerability (Privilege Escalation) is introduced is due to the use of the update_user_meta() function without any input validation or restrictions. We strongly recommend all developers utilize this function with hard coded options for the user meta keys that need to be updated through the functionality.

This can be done using an allow-list of user meta keys that can be updated, either user controlled via a setting or hard-coded in the plugin, and then checking if the user supplied value is in the list and only proceeding with the update if it is present in the allow-list.

We strongly advise against using deny lists alone to prevent arbitrary user meta options updates as these can often be bypassed through special techniques and methods.

Disclosure Timeline

  • August 14th, 2024 – We received the submission for the Privilege Escalation vulnerability in Post Grid and Gutenberg Blocks via the Wordfence Bug Bounty Program.
  • August 27th, 2024 – We validated the report and confirmed the proof-of-concept exploit.
  • August 28th, 2024 – Wordfence Premium, Wordfence Care, and Wordfence Response received a custom firewall rule to provide protection against any exploits targeting this vulnerability.
  • August 28th, 2024 – We sent over the full disclosure details via the vendor’s contact address we have on file.
  • September 5th, 2024 – The vendor reported back letting us know that they have released a patched version. A fully patched version of the plugin, 2.2.91, was released.
  • September 27th, 2024 – Wordfence free users receive the same protection.

Conclusion

In this blog post, we detailed an Privilege Escalation vulnerability within the Post Grid and Gutenberg Blocks plugin affecting versions 2.2.87 through 2.2.90. This vulnerability allows authenticated threat actors with subscriber-level permissions or higher to elevate their privileges to that of an administrator which leads to complete site compromise. The vulnerability has been addressed in version 2.2.91 of the plugin.

We encourage WordPress users to verify that their sites are updated to the latest patched version of Post Grid and Gutenberg Blocks as soon as possible considering the critical nature of this vulnerability.

Wordfence Premium, Wordfence Care, and Wordfence Response users received a custom firewall rule to provide protection against any exploits targeting this vulnerability on August 28th, 2024. Wordfence free users will receive the same protection 30 days later on September 27th, 2024.

If you know someone who uses this plugin on their site, we recommend sharing this advisory with them to ensure their site remains secure, as this vulnerability poses a significant risk.

Did you enjoy this post? Share it!

Comments

No Comments

All comments are moderated before being published. Inappropriate or off-topic comments may not be approved.