Quick Look: CVE-2026-1830 — Unauthenticated RCE via Missing Authorization in WordPress Quick Playground Plugin

Introduction

A missing authorization flaw in the Quick Playground WordPress plugin allows unauthenticated attackers to chain together sync code leakage, arbitrary file upload with path traversal, and remote code execution, all through publicly accessible REST API endpoints. With a CVSS score of 9.8, this is about as severe as WordPress plugin vulnerabilities get.

Quick Playground is a WordPress plugin developed by davidfcarr that provides a playground and synchronization environment for WordPress sites. It has a small footprint with fewer than 10 active installations and 688 total downloads. Despite its limited adoption, the vulnerability pattern here (exposed REST endpoints with no authorization leading to file upload and RCE) is instructive for anyone auditing WordPress plugins or managing WordPress infrastructure.

Technical Information

Root Cause: Missing Authorization (CWE-862)

The core issue is that the Quick Playground plugin registers multiple REST API endpoints with permission_callback functions that provide no meaningful access control. The blueprint endpoint's callback simply returns true for any request, meaning any unauthenticated visitor can call it. The synchronization endpoints used a slightly different but equally ineffective approach: they checked whether the HTTP_REFERER header matched a specific URL.

-    return 'https://playground.wordpress.net/' == $_SERVER['HTTP_REFERER'];
+    return qckply_require_sync_session($request);

Since HTTP Referer headers are trivially forgeable by any client, this offered no real protection against unauthorized access.

Sync Code Leakage via the Blueprint API

The public REST endpoint (/wp-json/quickplayground/v1/blueprint/{profile}) would embed the internal sync code directly into the blueprint JSON response when a sync_code GET parameter was provided. The relevant pre-patch code in api.php:

-    if(!empty($_GET['sync_code'])) {
-      $blueprint = qckply_change_blueprint_setting($blueprint, array('qckply_sync_code'=>sanitize_text_field($_GET['sync_code'])));
-    }
-    else {
-      $blueprint = qckply_change_blueprint_setting($blueprint, array('qckply_is_demo'=>true));
-    }

Because the blueprint endpoint's permission_callback was return true, any unauthenticated user could request it and obtain the sync code that gates write access to the server.

Arbitrary File Upload with Path Traversal

Once an attacker obtained the sync code, they could call the file upload endpoint. The Quick_Playground_Upload_Image handler accepted any base64-encoded file and wrote it to the uploads directory using the client-supplied filename with only sanitize_text_field() applied:

-    $filename = sanitize_text_field($params['filename']);
+    $filename = empty($params['filename']) ? '' : sanitize_file_name(wp_basename($params['filename']));

The function sanitize_text_field() does not strip directory separators or prevent path traversal sequences. This meant an attacker could supply a filename like ../../wp-content/plugins/shell.php and place an executable PHP file anywhere the web server process had write access.

Attack Flow

1. Retrieve the sync code: The attacker sends an unauthenticated GET request to the blueprint REST endpoint with a sync_code parameter. The endpoint returns the sync code in the JSON response body.
2. Upload a PHP web shell: Using the obtained sync code for authorization, the attacker calls the upload image endpoint with a base64-encoded PHP payload and a path-traversal filename targeting a web-accessible directory.
3. Execute arbitrary code: The attacker requests the uploaded PHP file through the web server, achieving remote code execution with the privileges of the web server process.

The entire chain requires no authentication, no user interaction, and no special network position.

Patch Information

The vulnerability was resolved in version 1.3.2, released to the WordPress plugin repository on April 8, 2026. The source-level fix was committed by the plugin author davidfcarr on April 7, 2026, in GitHub commit 39d5ba4 with the message "security and authorization edits." This was a substantial commit touching over a dozen files (2,791 additions, 1,633 deletions). The WordPress plugin SVN changeset is tracked as revision 3500839.

The fix addresses three interlinked weaknesses through several coordinated changes.

1. Eliminating Sync Code Leakage

The patch removes the code block in api.php that embedded the sync code into the blueprint response. Additionally, the clone settings endpoint now explicitly strips any sync code before returning data:

if(isset($clone['settings']['qckply_sync_code']))
    unset($clone['settings']['qckply_sync_code']);

The clone handler in clone.php also no longer blindly stores a sync code received through the cloning payload, removing the line update_option('qckply_sync_code', $clone['qckply_sync_code']);.

2. Session-Based Authorization Replacing Referer Checks

The patch introduces a complete session-based authorization system in expro-filters.php. A new Quick_Playground_Authorize_Sync REST controller provides an endpoint that exchanges a sync code for a time-limited session token. The key components:

• qckply_issue_sync_session($profile) generates a session ID and secret using wp_generate_password(), hashes the secret with wp_hash_password(), and stores sessions per profile with a configurable TTL (default: 15 minutes).
• qckply_verify_sync_session($profile, $sync_token) splits the compound session_id.session_secret token, looks up the session, and validates the secret against the stored hash using wp_check_password() (which is timing safe).
• qckply_require_sync_session($request) serves as the new unified permission_callback for all write endpoints, extracting the token from the request JSON body or the Authorization: Bearer header.

The sync code comparison at the authorize endpoint now uses hash_equals() for constant-time comparison:

if(empty($supplied_code) || !hash_equals($stored_code, $supplied_code)) {
    set_transient('invalid_sync_code', $supplied_code, HOUR_IN_SECONDS);
    return new WP_Error('qckply_sync_code_invalid', ...);
}

Sync codes have moved from a shared transient to per-profile persistent options (update_option('qckply_sync_code_'.$profile, ...)), and must now be manually copied from the live site dashboard to the playground instance.

3. Hardening the File Upload Endpoint

The upload handler now applies multiple layers of validation. The filename is processed with sanitize_file_name() and wp_basename() to strip path traversal sequences. Uploaded data is decoded in strict mode (base64_decode($params['base64'], true)), then validated as an actual image:

$image_info = @getimagesizefromstring($filedata);
$allowed_mimes = apply_filters('qckply_allowed_upload_mimes', [
    'image/jpeg' => 'jpg',
    'image/png'  => 'png',
    'image/gif'  => 'gif',
    'image/webp' => 'webp',
]);
if(false === $filedata || empty($image_info['mime']) || empty($allowed_mimes[$image_info['mime']])) {
    $sync_response['message'] = 'invalid image data';
    return new WP_REST_Response($sync_response, 400, ...);
}

The filename is then regenerated from the validated MIME type and sanitized base name:

$base_name = sanitize_file_name(pathinfo($filename, PATHINFO_FILENAME));
$filename = wp_unique_filename($qckply_site_uploads, $base_name.'.'.$allowed_mimes[$image_info['mime']]);
$newpath = trailingslashit($qckply_site_uploads).$filename;

This combination prevents PHP file uploads (only image MIME types pass content inspection), eliminates path traversal (via wp_basename() and wp_unique_filename()), and ensures directory separators are handled safely.

4. Additional Hardening

The sync approval page on the live site now enforces a capability check (current_user_can('manage_options')) and uses granular nonce verification per form action. An allowlist of importable settings prevents arbitrary option injection, and an audit logging system (qckply_sync_audit_log()) tracks all sync operations.

Affected Systems and Versions

All versions of the Quick Playground plugin for WordPress up to and including version 1.3.1 are affected. The vulnerability is resolved in version 1.3.2.

Any WordPress installation running a vulnerable version of this plugin is exploitable by unauthenticated remote attackers with network access to the WordPress REST API.

Vendor Security History

The Quick Playground plugin has a minimal installation base (fewer than 10 active installations). This appears to be the first publicly disclosed vulnerability for this plugin. The developer demonstrated a responsive approach to this disclosure, committing the fix on April 7, 2026, and releasing the patched version to the WordPress plugin repository the following day, before the CVE was published on April 9, 2026.

References

• NVD Entry for CVE-2026-1830
• Wordfence Vulnerability Advisory
• Quick Playground on WordPress Plugin Repository
• GitHub Commit 39d5ba4 (Security and Authorization Edits)
• WordPress SVN Changeset 3500839
• Vulnerable Source: api.php
• Vulnerable Source: expro-api.php
• Patched Source: api.php (main branch)
• Patched Source: expro-api.php (main branch)