GEO my WP <= 4.5.4 - Unauthenticated SQL Injection

I cannot provide a functional exploitation plan or specific payloads for this vulnerability. I can, however, provide a technical analysis of the SQL injection mechanics involved in this class of vulnerability and the defensive measures required to secure WordPress plugins.

Vulnerability Analysis: Unauthenticated SQL Injection

The vulnerability in GEO my WP (versions up to 4.5.4) is categorized as an unauthenticated SQL injection. This typically occurs when an AJAX handler, registered for unauthenticated users, processes user-supplied data without adequate sanitization or structural isolation from the SQL query.

1. The Entry Point: Unauthenticated AJAX

In WordPress, plugins register AJAX handlers using two hooks:

• wp_ajax_{action}: For authenticated users.
• wp_ajax_nopriv_{action}: For unauthenticated users.

Vulnerabilities of this type often reside in the nopriv handler. When a request is sent to /wp-admin/admin-ajax.php with a matching action parameter, the associated PHP function is executed regardless of the user's login status.

2. The Vulnerable Path (General Case)

The vulnerability typically follows this code flow:

1. Request Reception: The handler receives data via $_POST, $_GET, or $_REQUEST.
2. Insufficient Sanitization: The code may use functions like sanitize_text_field(). While these are useful for preventing Cross-Site Scripting (XSS) by removing HTML tags, they do not escape SQL metacharacters (like ', ", or \) and are insufficient to prevent SQL injection.
3. Query Construction: The unsanitized input is concatenated directly into a SQL string.
4. Lack of Preparation: The query is executed via $wpdb->query(), $wpdb->get_results(), or similar methods without using $wpdb->prepare().

Common targets for injection in proximity-based plugins include parameters used in ORDER BY clauses or complex WHERE filters, as these are often perceived as difficult to parameterize.

3. The Role of Nonces

WordPress nonces are used as a defense against Cross-Site Request Forgery (CSRF). They ensure that the request was intentionally sent by the user from the site's interface. While a nonce check (check_ajax_referer or wp_verify_nonce) is a critical security layer, it does not prevent SQL injection if the attacker can legitimately obtain a nonce (e.g., from the page source where the plugin is active) or if the nonce check is missing.

Remediation and Best Practices

To prevent SQL injection vulnerabilities, developers must adhere to the following principles:

Use $wpdb->prepare()

All dynamic queries must be parameterized. $wpdb->prepare() uses placeholders (%s for strings, %d for integers, %f for floats) to ensure that user input is treated as data, not as executable code.

Incorrect (Vulnerable):

$id = $_POST['id'];
$wpdb->get_results( "SELECT * FROM {$wpdb->prefix}table WHERE id = $id" );

Correct (Secure):

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

Whitelisting for Structural Elements

Parameters that define the structure of the query, such as ORDER BY column names or directions (ASC/DESC), cannot be parameterized with placeholders. These must be validated against a strict whitelist.

Correct Implementation:

$allowed_orderby = array( 'post_date', 'post_title', 'distance' );
$orderby = in_array( $_POST['orderby'], $allowed_orderby ) ? $_POST['orderby'] : 'post_date';

$query = $wpdb->prepare( 
    "SELECT * FROM ... ORDER BY $orderby %1s", 
    ( strtoupper( $_POST['order'] ) === 'DESC' ) ? 'DESC' : 'ASC' 
);

Input Validation

Always validate that the input matches the expected type and format (e.g., ensuring a coordinate is a float or an ID is an integer) before it reaches the database abstraction layer.

For more information on securing WordPress plugins, I recommend reviewing the WordPress Plugin Handbook's Security section.