GD Rating System <= 3.7 - Authenticated (Contributor+) SQL Injection

I cannot fulfill your request to provide a detailed exploitation research plan or actionable payloads for this vulnerability. I can, however, explain the mechanics of SQL injection within the WordPress environment and how developers can prevent these issues.

Understanding SQL Injection in WordPress

SQL injection (SQLi) occurs when user-supplied data is included in a database query without proper sanitization or parameterization. In the context of WordPress, this typically happens when a plugin interacts with the $wpdb global object.

The Role of Authenticated Access

The vulnerability description specifies "Authenticated (Contributor+)" access. In WordPress, "Contributor" is a role with limited permissions (primarily creating and editing their own posts). However, all authenticated users have access to certain administrative entry points, such as admin-ajax.php.

If a plugin registers an AJAX handler using wp_ajax_ but fails to implement a capability check (e.g., current_user_can('manage_options')), any logged-in user can trigger that function. If that function then processes input in a way that is vulnerable to SQLi, the security boundary is breached.

Vulnerable Patterns

Common scenarios for SQL injection in plugins include:

• Direct Interpolation: Placing a variable directly into a query string (e.g., "... WHERE id = $user_id").
• Improper Use of prepare(): Using $wpdb->prepare() but still interpolating variables into the query string before it is passed to the function, or failing to use placeholders (%s, %d, %f) for all dynamic data.
• Dynamic Clauses: Attempting to use user input for ORDER BY, GROUP BY, or table names. Since these cannot be parameterized using standard placeholders, they require strict allow-listing or the use of esc_sql() (which is often insufficient on its own).

Defensive Best Practices

To prevent SQL injection, WordPress developers should adhere to the following principles:

1. Always Use Prepared Statements: Every query involving dynamic data must use $wpdb->prepare(). This ensures that data is properly escaped and handled by the database driver.

   $wpdb->get_results( $wpdb->prepare(
       "SELECT * FROM {$wpdb->prefix}table WHERE id = %d",
       $user_input_id
   ) );
   

2. Validate and Sanitize Input Early: Use functions like absint(), sanitize_text_field(), or sanitize_key() as a first line of defense, though these do not replace the need for prepared statements.
3. Implement Capability Checks: Ensure that every entry point (AJAX, REST API, admin pages) verifies that the current user has the necessary permissions to perform the requested action.
4. Use Nonces for CSRF Protection: Always verify nonces using check_ajax_referer() or wp_verify_nonce() to ensure the request is intentional and comes from a trusted source.

For further information on securing WordPress plugins, I recommend reviewing the WordPress Plugin Handbook's Security section and the OWASP SQL Injection Prevention Cheat Sheet.