CVE-2025-13361 Exploit & Vulnerability Analysis

The Exploit

Attacker needs to trick a logged-in WordPress administrator into issuing a forged POST request.

POST /wp-admin/admin.php?page=wpscl-map-fields HTTP/1.1
Host: target.example.com
Cookie: wordpress_logged_in_abcd=YOUR_ADMIN_SESSION_COOKIE
Content-Type: application/x-www-form-urlencoded
Content-Length: 6

pid=42

The response body from the vulnerable site will include Field deleted successfully and the row in the wpscl_map_fields table matching pid=42 is removed. Because the plugin never checks a nonce on this delete action, a remote attacker can induce an admin browser to submit this request without any additional authentication beyond the existing admin session.

What the Patch Did

Before:

if (isset($_POST['pid'])) {
    $pid = absint($_POST['pid']);
    $where = array('pid' => $pid);
    $delete = $wpdb->delete(WPSCL_TBL_MAP_FIELDS, $where);
    if ($delete !==false) {
        echo esc_html__('Field deleted successfully', 'WPSCL');
    } else {
        echo esc_html__('Error occured ! Please try again', 'WPSCL');
    }
}

After:

check_ajax_referer('WPSCL', 'wpscl_nonce');

if (!isset($_POST['pid'])) {
    wp_die(esc_html__('Invalid request.', 'WPSCL'), 'Error', array('back_link' => true));
}

$pid = absint($_POST['pid']);
$where = array('pid' => $pid);
$delete = $wpdb->delete(WPSCL_TBL_MAP_FIELDS, $where);
if ($delete !==false) {
    echo esc_html__('Field deleted successfully', 'WPSCL');
} else {
    echo esc_html__('Error occured ! Please try again', 'WPSCL');
}

The patch adds a WordPress nonce verification call: check_ajax_referer('WPSCL', 'wpscl_nonce'). That is the request authenticity check missing from the original delete handler. The added wp_die() branch also hardens malformed requests by failing explicitly when pid is absent.

Root Cause

This is a classic CSRF bug, CWE-352. The handler accepts attacker-controlled input from $_POST['pid'] and passes it directly to $wpdb->delete() without any verification that the request was intentionally issued by the logged-in admin. The trust boundary crossed unchecked is the authenticated admin session: the browser is trusted to submit any POST to the plugin's delete endpoint, even when the request originates from a malicious page. pid is the only parameter needed to trigger the destructive sink.

Why It Works

The load-bearing line is check_ajax_referer('WPSCL', 'wpscl_nonce');. If you remove that line, the handler remains exploitable because nothing else in the original code verifies that the request came from a legitimate admin page. The wp_die() check is supplementary: it makes invalid requests fail more cleanly, but it does not stop CSRF. absint() is good for type safety on pid, but it only limits the value format, not the origin of the request.

Hardening Checklist

• Use check_ajax_referer() or wp_verify_nonce() for any state-changing admin POST endpoint.
• Protect AJAX and form actions with a nonce field named consistently, e.g. wpscl_nonce.
• Verify required parameters explicitly before executing destructive logic (if (!isset($_POST['pid'])) wp_die(...)).
• Keep destructive handlers inside authenticated admin pages and verify capabilities where appropriate (current_user_can('manage_options') when a plugin action affects configuration or schema).
• Avoid trusting browser state alone; require a nonce on every single custom action that modifies the database.

References

• https://nvd.nist.gov/vuln/detail/CVE-2025-13361